Abstract 


Each  year,  the  UNC-CH  Operations  Research  Department  invites  community  organizations  to  be  involved 
as  clients  in  the  Operations  Research  Practice  course.  Interested  organizations  can  volunteer  to  have  a 
student  work  on  an  OR-type  problem  for  them  over  the  course  of  a  semester.  The  OR  Practice  course 
instructor  chooses  interesting  problems  from  among  those  submitted  and  assigns  a  client  to  each  student. 
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Summary; 

To  address  the  heavy  dispatching  workload  and  communications  challenges  in  its  paratransit  operations, 
Chapel  Hill  Transit  (CHT)  requested  that  the  Operations  Research  Department  of  the  University  of  North 
Carolina  at  Chapel  Hill  conduct  a  study  on  the  potential  costs  and  benefits  of  adding  mobile  data  terminals 
(MDT’s)  to  CHT’s  current  system.  A  new  type  of  transportation  technology,  an  MDT  is  a  small  computer 
terminal  mounted  in  the  vehicle  that  communicates  directly  with  the  dispatcher’s  central  computer  via  a 
communications  network. 

This  study  addressed  this  issue.  It: 

•  Evaluated  current  CHT  paratransit  operations  from  four  perspectives:  dispatcher,  driver,  customer, 
and  data  collection.  This  was  accomplished  by  observation  and  quantitative  analysis  of  dispatcher’s 
booth  activity;  vehicle  ride  observation;  discussion  with  dispatchers,  drivers,  and  administrators; 
distribution  of  a  driver  survey;  and  analysis  of  a  finite-source  retrial  queueing  model. 

•  Evaluated  potential  changes  in  operations  due  to  MDT’s  from  the  same  four  perspectives. 

•  Researched  what  steps  would  be  necessary  to  implement  a  mobile  data  system. 

•  Surveyed  different  MDT  vendors  to  assess  the  benefits  and  costs  of  each  product  that  was  found  to  suit 
CHT’s  needs. 

•  Analyzed  the  anticipated  costs  of  adding  MDT’s. 
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Executtve  Summary 


Chapel  Hill  Transit  (CHT)  provides  various  forms  of  public  transportation  for  the  Chapel 
Hill  community.  In  addition  to  its  broad  spectrum  of  fixed-route  bus  services,  CHT 
offers  demand-responsive  services,  called  “paratransit”  services.  They  meet  a  wide  range 
of  special  transportation  needs,  including  service  to  locations  not  on  any  fixed  route, 
travel  during  off-peak  hours,  and  elderly  and/or  handicapped  transportation.  The  small 
size  of  its  paratransit  operation  allows  CHT  to  accommodate  customers  as  they  call  on  a 
first-come  first-served  basis. 

During  peak  times  of  day,  both  the  level  of  customer  calls  and  number  of  trips  being 
accomplished  are  high.  This  creates  considerable  demand  on  the  CHT  dispatcher’s  time. 
She  must  answer  customer  phone  calls,  book  future  trips  that  are  being  requested, 
dispatch  current  trips  to  vehicles,  record  information  regarding  trip  execution  (i.e.,  arrival, 
departure,  board,  and  alight  times)  for  all  CHT  vehicles  on  the  road,  and  maintain 
communication  with  drivers  all  at  the  same  time.  This  excessive  workload  can  affect 
length  of  customer  phone  calls,  quality  of  real-time  dispatching  decisions,  and  on-time 
trip  performance. 

All  dispatcher-driver  communication  currently  occurs  over  one  450MHz  UHF  radio 
frequency.  This  band  is  also  shared  by  bus  drivers.  The  high  volume  of  information 
transmitted  and  the  frequent  need  to  repeat  messages  can  be  both  frustrating  and  time- 
consuming  for  drivers  and  dispatchers. 

An  ideal  communications  system  would: 

•  Provide  dispatchers  with  adequate  time  to  make  better  dispatching  decisions  than  the 
current  system  permits. 

•  Speed  up  effective  communication  between  dispatchers  and  drivers,  and  reduce  the 
error  rate  in  communicating  between  them. 

•  Offer  a  higher  level  of  customer  service  to  callers  requesting  information  or  booking 
trips. 

•  Accommodate  the  transportation  needs  of  passengers  in  a  more  timely  manner. 

•  Generate  accurate  and  informative  reports  using  trip  execution  times  and  mileages. 

•  Provide  these  improvements  at  relatively  low  cost. 

To  address  its  dispatching  workload  and  communications  challenges,  CHT  requested  that 
the  Operations  Research  Department  of  the  University  of  North  Carolina  at  Chapel  Hill 
conduct  a  study  on  the  potential  costs  and  benefits  of  adding  mobile  data  terminals 
(MDT’s)  to  CHT’s  current  system.  A  new  type  of  transportation  technology,  an  MDT  is 
a  small  computer  terminal  mounted  in  the  vehicle  that  communicates  directly  with  the 
dispatcher’s  central  computer  via  a  communications  network. 


This  study  addressed  this  issue.  It: 

•  Evaluated  current  CHT  paratransit  operations  from  four  perspectives:  dispatcher, 
driver,  customer,  and  data  collection.  This  was  accomplished  by  observation  and 
quantitative  analysis  of  dispatcher’s  booth  activity;  vehicle  ride  observation; 
discussion  with  dispatchers,  drivers,  and  administrators;  and  distribution  of  a  driver 
survey. 

•  Evaluated  potential  changes  in  operations  due  to  MDT’s  from  the  same  four 
perspectives. 

•  Researched  what  steps  would  be  necessary  to  implement  a  mobile  data  system. 

•  Surveyed  different  MDT  vendors  to  assess  the  benefits  and  costs  of  each  product  that 
was  found  to  suit  CHT’s  needs. 

•  Analyzed  the  anticipated  costs  of  adding  MDT’s. 

Major  findings  of  this  study  are: 

•  Currently,  the  dispatcher  spends  an  average  of  19.4  minutes  per  hour  on  the  phone  or 
radio. 

•  With  MDT’s,  M>e  estimate  that  this  time  would  be  reduced  to  11.0  minutes  (a  43% 
reduction). 

•  Currently,  the  dispatcher  manually  enters  all  trip  data,  which  is  both  time-consuming 
and  prone  to  error  in  terms  of  recording  trip  performance  time. 

•  With  MDT’s,  trip  performance  data  would  be  automatically  transmitted from  vehicle 
to  office,  helping  to  eliminate  recording  errors  and  providing  additional  time  for  the 
dispatcher  to  perform  additional  tasks. 

•  Currently,  the  use  of  voice  radio  causes  frequent  unsuccessful  call  attempts  and 
necessitates  message  repetition. 

•  With  MDT’s,  information  transfer  would  occur  upon  the  driver  ’s/dispatcher ’s  first 
attempt  to  send  trip  data. 

•  Currently,  CHT  does  not  have  the  means  to  collect  information  accurately  on  trip  stop 
and  start  times,  dwell  times,  and  trip  mileages. 

•  MDT’s  would  automatically  provide  a  time  and  mileage  stamp  with  every  trip 
performance.  Combined  with  their  user-definable  reporting  capabilities,  they  would 
provide  a  more  comprehensive  reporting  tool  to  CHT  than  it  currently  has. 

•  Implementing  MDT’s  would  require  acquiring  an  additional  UHF  radio  channel.  The 
license  for  a  new  frequency  would  cost  under  $300. 

•  Implementing  MDT’s  would  require  a  contract  with  Trapeze  Software  Group  to 
interface  Minipass ,  its  dispatching  software  which  CHT  already  has,  with  the  MDT 
software.  This  contract  would  include  the  interface  itself,  engineering,  and  training, 
and  would  cost  approximately  $32,000  initially,  followed  by  about  $2,000  annually. 
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•  GMSI,  Inc.  and  Mentor  Engineering  both  offer  MDT’s  that  would  meet  CHT’s  needs. 
Mentor  Engineering  provides  the  more  cost-effective  option  and  has  more  experience 
in  implementing  mobile  data  systems  in  paratransit  operations.  The  cost  of  the 
Mentor  contract  is  about  $34,000  initially,  along  with  an  annual  maintenance/upgrade 
cost  of  $2,500. 

•  The  costs  to  implement  MDT’s  would  total  about  $66,500  initially,  followed  by  about 
$4,500  annually. 

Based  upon  these  findings,  we  recommend: 

1 .  CHT  should  consider  MDT’s  as  a  good  option  to  improve  current  paratransit 
operations  in  these  ways: 

•  reduced  dispatcher  workload,  allowing  more  time  for  better  dispatching  decisions 
and  caller  service 

•  faster,  clearer,  and  less  error-prone  driver/dispatcher  communication 

•  more  on-time  trips 

•  trip  time  and  mileage  reporting  capabilities 

2.  CHT  should  decide  whether  it  will  make  a  long-term  commitment  to  using  Minipass. 
If  so,  it  will  be  in  a  position  to  begin  the  process  of  installing  MDT’s.  If  not,  CHT 
will  need  to  do  further  research  to  commit  to  another  dispatching  software  package 
before  installing  an  MDT  system. 

If  CHT  decides  to  implement  MDT’s,  we  also  recommend: 

1 .  CHT  should  pursue  Mentor  Engineering  as  the  best  vendor  option  for  this  system.  Mr. 
Brent  Freer,  the  sales  representative  we  worked  with  during  the  study,  is  the  point  of 
contact.  CHT  should  arrange  for  a  visit  and  presentation  from  the  company. 

2.  CHT  should  take  early  steps  to  gain  the  second  radio  frequency  needed  for  the  MDT 
system.  Mr.  Dyke  Hostettler,  State  Frequency  Coordinator  for  North  Carolina,  is  the 
point  of  contact.  It  should  also  contact  a  radio  consultant,  possibly  Mr.  Larry  Sparks, 
to  consider  the  possibility  of  using  his  services  to  ensure  an  adequate  radio  system. 

3.  CHT  should  begin  to  work  toward  a  contract  with  Trapeze  Software  Group  for  the 
MDT  -  Minipass  interface.  The  point  of  contact  is  Mr.  Dean  Richardson.  The 
contract  should  contain  a  commitment  from  Trapeze  to  staying  until  the  interface  is 
running  smoothly,  since  CHT  would  be  the  first  Minipass-MDT  interface  site. 
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Chapter  1: 

Overview  and  Introduction 


1.1  Project  Background 


Chapel  Hill  Transit  (CHT)  provides  various  forms  of  public  transportation  for  the  Chapel 
Hill  community.  In  addition  to  its  wide  range  of  fixed-route  bus  services,  CHT  offers 
demand-responsive  services.  These  special  “paratransit”  services  meet  a  wide  range  of 
special  transportation  needs,  including  service  to  locations  not  on  any  fixed  route,  travel 
during  off-peak  hours,  and  elderly  and/or  handicapped  transportation.  The  small  size  of 
its  paratransit  operation  allows  CHT  to  accommodate  customers  as  they  call  on  a  first- 
come  first-served  basis.  In  addition  to  dispatching  vehicles,  the  dispatcher  takes  customer 
phone  calls  and  schedules  trips.  With  this  setup,  the  system  has  a  great  deal  of  flexibility, 
but  it  is  also  prone  to  becoming  overloaded  during  peak  hours. 

All  dispatcher-driver  communication  currently  occurs  over  one  radio  frequency  band. 

This  band  is  also  shared  by  bus  drivers.  The  high  volume  of  information  transmitted  and 
the  frequent  need  to  repeat  poorly-understood  messages  often  cause  delays.  Dispatchers 
spend  a  significant  portion  of  their  limited  and  valuable  time  talking  over  the  radio. 

Until  December  1996,  all  trip  information  such  as  passenger  name,  pickup  time  and 
place,  destination,  and  fare,  was  logged  manually  by  the  dispatcher.  CHT  has  recently 
begun  to  use  a  computer-aided  dispatch  (CAD)  software  package  called  Minipass  to 
record  these  data.  The  package  has  replaced  hand- written  logs  and  provides 
administrators  with  a  helpful  reporting  tool.  However,  the  dispatcher  still  has  to  spend 
time  booking  trips  and  entering  trip  data  into  the  system. 

In  recent  years,  the  transportation  industry  has  begun  to  make  use  of  mobile  data 
technology  to  improve  communications  and  operational  efficiency.  Both  Winston-Salem 
and  Charlotte  have  made  the  decision  to  implement  mobile  data  systems  in  their 
paratransit  systems.  A  principal  component  of  these  systems  is  the  mobile  data  terminal 
(MDT).  It  is  a  small  terminal  mounted  in  the  vehicle  which  communicates  directly  with 
the  dispatcher’s  computer  via  some  communications  network. 

Mr.  Scott  McClellan,  CHT’s  administrative  analyst,  was  concerned  about  the  paratransit 
system’s  dispatching  overload  and  communications  issues.  He  recognized  that 
identifying  and  overcoming  these  problems  would  increase  customer  service  and 
employee  satisfaction.  He  requested  that  the  Operations  Research  Department  of  the 
University  of  North  Carolina  at  Chapel  Hill  conduct  a  study  on  the  potential  costs  and 
benefits  of  adding  MDT’s  to  CHT’s  current  system. 
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1.2  Project  Overview 


This  project  involved  observing  current  paratransit  service  and  researching  the  potential 
effects  of  using  MDT’s  in  the  context  of  CHT’s  operational  environment.  The  costs 
associated  with  implementing  this  technology  were  also  assessed. 

The  evaluation  of  current  paratransit  service  was  accomplished  in  several  ways; 

•  Spending  time  in  the  dispatcher’s  booth,  which  included  discussion  with 
dispatchers,  data  collection  on  radio  and  phone  call  activity,  and  qualitative 
observation  of  operations. 

•  Analyzing  radio  and  call  data  to  estimate  dispatcher  busy  time. 

•  Riding  on  paratransit  vehicles. 

•  Conducting  a  driver  survey  which  addressed  issues  that  came  up  as  a  result  of 
vehicle  rides. 

•  Discussing  desired  reporting  capabilities  with  Mr.  McClellan. 

The  effects  of  MDT’s  on  the  system  were  predicted  by  considering  observations  made 
about  current  operations.  Dispatcher  busy  time  estimates  from  booth  observations  were 
modified  to  reflect  the  use  of  MDT’s,  and  drivers  were  surveyed  to  gage  their  response  to 
the  possibility  of  having  them  on  their  vehicles.  In  addition,  several  cities  with  systems 
already  in  place  were  contacted  in  order  to  learn  what  benefits  and  drawbacks  they  have 
experienced  from  using  the  technology. 

Based  on  our  study  of  current  operations,  data  analysis,  and  surveys,  the  study  concluded 
that  adding  MDT’s  to  the  system  will  benefit  CHT  by: 

•  Reducing  the  percentage  of  dispatcher’s  time  on  phone  and  radio 

•  Eliminating  the  need  for  dispatcher  to  manually  enter  trip  data 

•  Eliminating  delays  due  to  message  repetitions. 

•  Eliminating  delays  due  to  multiple  call-outs  by  dispatcher 

•  Eliminating  delays  due  to  multiple  attempts  by  driver  to  contact  dispatcher 

•  Reducing  incidence  of  vacant  and  idle  vehicles 

•  Inducing  positive  driver  reaction  to  MDT’s 

•  Improving  real-time  credibility  in  reporting  trip  status  to  customers 

•  Enhancing  reporting  capabilities  due  to  time  and  mileage  stamping 

•  Improved  customer  service  resulting  from  each  of  the  above  improvements 
(from  the  customer’s  booking  phone  call  to  her  actual  trip. 

Additionally,  the  study  involved  investigation  to  discover  what  actions  and  costs  would 
be  involved  in  implementing  MDT’s.  This  was  a  multi-step  process  which  included 
interviews  with  several  people  regarding  communications  network  opportunities,  MDT 
vendors,  and  contracting  with  Trapeze.  One  source  of  costs  is  the  communications 
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network  necessary  to  transmit  data  from  the  MDT  to  the  central  computer.  Research 
revealed  that  CHT  would  be  able  to  gain  a  second  UHF  frequency  for  an  application  fee 
of  under  $300.  Additionally,  a  contract  with  Trapeze  will  be  required  to  purchase  the 
MDT  interface  for  Minipass  and  to  pay  for  associated  engineering  and  training.  This  cost 
was  estimated  to  be  about  $32,000. 

Initial  contact  with  several  mobile  data  systems  and  transportation  management 
companies  indicated  that  two  companies  offered  products  that  would  meet  CRT’s  needs. 
These  needs  were  defined  by  the  facts  that  Chapel  Hill  has  a  computer-aided  dispatch 
(CAD)  system.  Trapeze  Software’s  Minipass,  already  in  place,  and  it  has  a  small  fleet. 

Both  GMSI,  Inc.  and  Mentor  Engineering  offered  a  mobile  data  terminal  with  software 
that  interfaces  with  Trapeze’s  CAD  system.  The  two  companies  were  compared  in  terms 
of  company  background,  experience  with  paratransit  systems,  experience  with  Trapeze 
CAD  interface,  product  specifications  and  functionality,  client  feedback,  and  system 
costs.  Mentor  gave  an  estimate  of  about  $34,000,  while  GMSI  gave  an  estimate  of  about 
$47,000.  The  major  difference  in  price  is  due  to  the  companies’  differing  estimates  of 
engineering  costs.  Overall,  the  findings  of  this  study  indicate  that  Mentor  is  the  better 
option  for  CHT  because  of  its  lower  cost,  experience  with  paratransit  and  Trapeze- 
interfaced  systems,  and  favorable  customer  response. 

In  summary,  this  study  finds  that  MDT’s  would  be  of  significant  benefit  to  CHT  in 
improving  the  quality  of  paratransit  operations.  Both  GMSI  and  Mentor  offer  MDT 
systems  which  are  appropriate  for  the  needs  of  CHT.  This  investigation  points  to  Mentor 
as  the  better  vendor  option,  and  the  estimated  overall  cost  of  this  system  would  be  about 
$66,500. 
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1.3  Report  Overview 

This  report  is  divided  into  five  chapters.  Chapter  2  details  findings  on  the  potential 
effects  of  MDT’s  on  current  operations.  Section  2.1  considers  these  effects  from  the 
perspective  of  the  driver.  It  includes  results  from  the  dispatcher  “busy  time”  analysis, 
including  incoming  rate  of  phone  and  radio  calls  per  hour,  average  duration  of  these  calls, 
and  percentage  of  time  that  the  dispatcher  is  either  on  the  phone  or  radio.  In  addition,  it 
addresses  trip  data  entry,  radio  call  repetitions,  and  multiple  call-outs. 

Section  2.2  considers  the  issue  from  the  driver’s  perspective.  It  addresses  the  problems  of 
multiple  driver  attempts  to  reach  the  dispatcher,  radio  call  repetitions,  and  standing  by  in 
vacant  vehicles.  Finally,  it  contains  results  of  a  driver  survey  indicating  driver  attitudes 
toward  the  prospect  of  using  MDT’s  in  their  vehicles. 

Section  2.3  considers  the  effects  of  MDT’s  from  a  reporting  standpoint,  including  real¬ 
time  credibility,  time  and  mileage  stamping,  and  flexibility  in  data  collection.  Section  2.4 
discusses  how  findings  in  the  previous  sections  will  affect  customer  service. 

Chapter  3  deals  with  MDT  implementation.  Implementation  actions  fall  into  three 
categories,  which  are  presented  in  Section  3.1.  Sections  3.2,  3.3,  and  3.4  address 
choosing  a  communications  network,  establishing  a  Minipass-MDT  interface  contract 
with  Trapeze,  and  choosing  an  MDT  vendor,  respectively.  Recommendations  for  how  to 
best  accomplish  these  actions  are  summarized  in  Section  3.5. 

Chapter  4  contains  detailed  results  from  our  research  of  MDT  vendors.  GMSI,  Inc.  and 
Mentor  Engineering  are  considered  in  Sections  4.2  and  4.3.  Each  section  contains: 

•  Information  about  the  company  itself 

•  Information  about  the  company’s  experience  in  providing  mobile  data  systems 
to  paratransit  fleets 

•  Description  of  the  company’s  product 

•  Comments  and  contact  information  from  company  clients  who  have  MDT’s 
installed  on  their  paratransit  fleets 

Section  4.4  lists  other  vendors  that  were  considered,  but  ruled  out  early  in  the  process. 
Section  4.5  summarizes  findings  and  makes  a  vendor  recommendation  based  on  this 
summary. 

Chapter  5  contains  a  summary  of  our  findings  during  the  course  of  this  project  and,  based 
on  these  findings,  makes  our  recommendations  to  CHT. 
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Chapter!: 

Potential  Effects  of  MDT’s  on 
Current  Paratransit  Operations 


2.1  Dispatcher  Perspective 

The  dispatcher  has  several  responsibilities.  He  must; 

•  Answer  all  demand-responsive  customer  phone  calls.  These  calls  may  be  requests  to 
book  trips  up  to  two  weeks  in  advance,  cancel  trips,  or  find  out  about  the  status  of  a 
trip.  There  are  two  customer  phone  lines  for  the  dispatcher  to  monitor. 

•  Maintain  communication  with  all  paratransit  vehicles  en  route.  The  dispatcher  tells 
each  driver  his  or  her  next  destination(s),  passenger(s),  and  where  passenger(s)  need 
to  go.  The  driver  radios  the  dispatcher  every  time  she  picks  up  or  drops  off  a 
passenger  and  relays  name,  location,  and  type  of  fare  paid.  The  radio  is  also  used  to 
give  directions  to  unfamiliar  addresses,  confirm  driver  location,  and  deal  with 
emergencies. 

•  Use  Minipass  dispatching  software  to  accomplish  trip-booking  and  dispatching. 

•  Dispatch  trips.  The  dispatcher  does  not  use  Minipass  to  assign  trips  to  vehicles  ahead 
of  time.  Instead,  she  assigns  these  trips  less  than  an  hour  in  advance  based  on  real¬ 
time  activity.  This  requires  both  thought  and  time. 

Juggling  these  responsibilities  can  be  challenging  during  the  busiest  hours  of  the  day,  as 
subsequent  subsections  show.  The  following  subsections  deal  with  how  current 
operations  affect  the  dispatcher. 

2.1.1  Dispatcher  Busy  Time  -  Quantitative  Analysis 

CHT  initially  expressed  concern  about  the  “sensory  overload”  faced  by  dispatchers  on  a 
daily  basis.  MDT’s  might  be  able  to  significantly  reduce  this  overload  by  reducing  radio 
traffic  and  data  entry  time. 

The  primary  quantitative  analysis  was  aimed  at  trying  to  provide  descriptive  estimates  of 
the  current  level  of  activity  in  the  dispatcher’s  booth  and  the  potential  change  in  activity 
level  with  the  introduction  of  MDT’s.  This  was  accomplished  by  estimating  current 
values  of: 

1 .  Average  rate  of  radio  call  occurrence 

2.  Average  rate  of  phone  call  occurrence 

3.  Average  radio  call  duration 

4.  Average  phone  call  duration 

5.  Average  dispatcher  busy  time  (percentage  of  the  time  that  the  dispatcher  is  occupied, 
either  by  a  radio  or  phone  call.) 

The  projected  dispatcher  busy  time  with  MDT’s  in  use  was  also  calculated  based  upon 
the  duration  of  current  radio  calls  which  would  not  be  able  to  be  handled  by  an  MDT. 

2.1. 1.1  Data  Collection 
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The  goal  in  collecting  data  in  the  dispatcher’s  booth  was  to  measure  phone  call  activity, 
radio  call  activity,  and  the  fraction  of  the  time  that  these  calls  occupy  the  dispatcher.  The 
assumption  was  that  these  averages  were  related  to  both  hour  of  the  day  and  day  of  the 
week.  Since  no  data  were  available,  the  first  decision  was  when  to  collect  these  data. 

Monitoring  of  the  dispatcher’s  booth  occurred  from  7:00  am  to  5:00  pm  on  two 
consecutive  Wednesdays.  The  basis  for  this  was  two-fold: 

1 .  As  an  alternative  to  observing  the  system  for  every  day  of  the  week,  the  client 
suggested  observation  of  the  system  on  the  busiest  day  of  the  week.  Discussion  with 
both  the  morning  and  afternoon  dispatchers  revealed  that  Wednesday  is  typically 
their  busiest  day. 

2.  Discussion  with  the  dispatchers  indicated  that  most  of  the  phone  call  activity  occurs 
between  8:00  am  and  3:00  pm.  Additionally,  examination  of  the  driver  schedule 
(Figure  1)  showed  the  most  vehicles  on  the  road  between  9:30-10:15  am  and  2:15- 
4:30  pm.  We  decided  to  observe  between  the  hours  of  7:00  am  and  5:00  pm  in  order 
to  capture  the  peak  period(s)  of  operations. 
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Figure  1 


In  the  dispatcher’s  booth,  data  were  collected  as  follows: 

•  The  start  and  stop  time  of  each  call  was  measured. 

•  Phone  calls  that  were  put  on  hold  were  accounted  for  by  recording  the  time  placed  on 
and  off  hold. 

•  Timing  started  when  the  phone  was  answered,  not  when  it  rang. 

•  One  radio  call  was  considered  to  be  one  incidence  of  information  exchange  between 
the  driver  and  dispatcher.  (In  reality,  this  exchange  may  have  required  both  the 
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dispatcher  and  driver  to  use  the  radio,  but  it  makes  sense  to  consider  this  as  just  one 
“call”.) 

•  Once  in  a  while,  a  start  time  or  stop  time  was  missed  due  to  a  high  level  of  aetivity  in 
the  dispatcher’s  booth.  Although  the  length  of  that  particular  call  could  not  be 
captured,  the  call  was  still  accounted  for  in  order  to  get  an  accurate  estimate  of  the 
rate  of  incoming  calls. 

•  Radio  calls  that  were  conducted  while  the  dispatcher  was  on  the  phone  were  marked 
as  such  in  order  to  avoid  double-eounting  time  for  the  busy  time  estimate. 

Radio  calls  which  were  not  routine  in  the  sense  that  they  would  not  have  been  able  to  be 
transmitted  by  MDT  (for  example,  asking  for  directions  to  an  address)  were  marked  as 
such  in  order  to  make  predictions  about  the  effects  of  MDT’ s  on  radio  traffic. 

Figures  2  and  3  show  results  of  a  compilation  of  the  data.  The  raw  data  that  were 
colleeted  are  not  included  in  this  report,  but  they  can  be  made  available  to  the  client  if 
desired. 

2.1. 1.2  Results 

Hourly  averages  were  determined  for  the  number  of  incoming  radio  and  phone  calls  and 
the  durations  of  radio  and  phone  calls.  These  averages  can  be  found  in  Appendix  A. 

The  call  rate  and  duration  averages  were  used  to  calculate  the  dispatcher’s  hourly  average 
busy  time  according  to  the  following  formula,  which  accounts  for  the  average  hourly  time 
spent  on  both  the  phone  and  radio,  corrected  for  any  “double-counting”  of  time  the 
dispatcher  spent  on  both  simultaneously: 

Hourly  Average  Busy  Time  = 

(Ave.  #  Radio  Calls  xAve.  Radio  Call  Length) 

+  (Ave.  #  Phone  Calls  xAve.  Phone  Call  Length) 

-  (Total  Time  Spent  on  Radio  and  Phone  Simultaneously) 


Figure  2  lists  the  observed  hourly  and  overall  busy  time  averages.  Note  that  the 
dispatcher  spent  over  20  minutes  per  hour  during  peak  hours  just  on  the  phone  and  radio. 
This  time  reflects  a  great  deal  of  switehing  back  and  forth  between  tasks,  as  well.  Adding 
data  entry  and  trip  dispatching  to  the  scenario  reflects  that  there  is,  in  fact,  an  overload  on 
the  dispatcher.  The  overall  observed  busy  time  was  19.4  minutes. 

In  order  to  estimate  the  effects  of  adding  MDT’s  to  the  system,  observed  radio  calls  were 
identified  to  categorized  as  either  MDT-transmittable  or  not  MDT-transmittable.  Hourly 
average  percentages  were  ealculated  reflecting  the  proportion  of  radio  traffic  that  would 
be  alleviated  with  the  addition  of  MDT’s.  These  are  listed  in  Figure  3.  The  overall 
estimated  percentage  of  MDT-Transmittable  Radio  Traffic  was  87%.  This  result  is  in 
agreement  with  an  estimate  found  in  Radio  Resource  magazine,  which  states  “Once 
employees  become  familiar  with  using  MDT’s,  voice  traffie  decreases  by  about  70-90 
percent  of  previous  use”  (Vol.  9,  No.  2;  March  1995,  p.41). 
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To  calculate  the  effect  on  dispatcher  busy  time  if  MDT’s  were  added  to  the  system,  this 
87%  estimate  was  used  to  modify  the  busy  time  formula  as  follows: 

Hourly  Average  Busy  Time  = 

(1-.87)  X  (Ave.  #  Radio  Calls  xAve.  Radio  Call  Length) 

+  (Ave.  a  Phone  Calls  xAve.  Phone  Call  Length) 

-  (Total  Time  Spent  on  Radio  and  Phone  Simultaneously) 

Figure  2  also  includes  these  results.  Note  that  MDT’s  would  cut  dispatcher  busy  time 
almost  in  half  during  peak  hours.  Based  on  this  study’s  observations,  MDT’s  are 
projected  to  reduce  dispatcher  phone  and  radio  busy  time  by  43%  overall. 
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Figure  4  -  Graph  of  Figure  2  Results 


2.1.3  Trip  Data  Entry 

Currently,  when  a  driver  picks  up  a  customer,  she  calls  the  dispatcher  to  confirm  that 
passenger  “x”  has  been  picked  up  at  location  “y”.  At  that  point,  the  dispatcher  should 
note  the  time  and  mark  that  leg  of  the  trip  as  having  been  completed.  Upon  arrival,  the 
driver  calls  again  to  confirm  passenger,  location,  and  type  of  fare  paid.  The  dispatcher 
enters  this  information  again.  The  following  aspects  of  this  process  were  observed  while 
in  the  dispatcher’s  booth: 

•  Marking  the  trip  as  “performed”  requires  scrolling  to  that  trip  followed  by  the 
keystroke  <F2>.  At  this  point,  the  computer  time  stamps  the  trip  performance. 

•  Adding  or  changing  any  trip  information,  such  as  type  of  fair  paid  or  arrival  time, 
requires  scrolling  to  that  trip  and  opening  another  screen  with  the  keystroke  <P>  to 
enter  the  appropriate  information. 

•  During  peak  hours,  it  is  not  uncommon  for  the  dispatcher  to  make  a  handwritten  or 
mental  note  of  the  trip  performance  information.  She  enters  it  at  a  later  time,  which 
leaves  room  for  error.  She  may  have  to  estimate  the  time  a  trip  performance  occurred, 
or  may  forget  altogether  and  have  to  call  the  driver  to  reconfirm  the  completion. 

These  observations  show  that  trip  data  entry  is  time-consuming:  the  driver  must  first 
relay  the  message  by  voice,  then  the  dispatcher  often  must  make  a  handwritten/mental 
note  before  entering  the  data  into  the  computer. 

With  MDT’s,  the  driver  would  enter  the  trip  performance  into  his  terminal  on 
the  vehicle.  The  keystroke  combination  would  be  simple,  as  the  MDT’s  we  are 
considering  have  built-in  function  keys  for  standard  operations  such  as 
arriving,  departing,  boarding,  and  alighting.  This  action  on  the  part  of  the 
driver  would  replace  both  the  radio  call  and  the  dispatcher  data  entry.  It  would 
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also  alleviate  the  data  entry  delay,  thereby  providing  a  more  accurate  time 
stamp. 

2.1.4  Repetitions  and  Multiple  Call-Outs 

Time  in  both  the  dispatcher’s  booth  and  on  vans  revealed  that  voice  messages  are  often 
difficult  to  understand.  In  part,  this  is  due  to  the  nature  of  UHF  radio  communication.  In 
addition,  some  areas  of  Chapel  Hill  have  poor  radio  coverage,  making  messages 
especially  difficult  to  decipher.  Finally,  sometimes  more  than  one  person  is  trying  to 
relay  information  at  once.  All  of  these  factors  contribute  to  the  frequent  need  for  the 
dispatcher  to  repeat  a  message. 

With  MDT’s,  the  dispatcher  would  assign  trips  to  drivers  in  the  Mini-PASS 
system.  This  information  would  be  automatically  sent  to  the  MDT’s, 
eliminating  problem  of  repetitions  on  behalf  of  the  dispatcher.  It  should  be 
noted  that  successful  data  transmission  is  dependent  on  a  reliable  radio  system. 

A  system  with  poor  coverage  might  require  more  than  one  attempt  before  data 
are  transmitted  successfully.  Nevertheless,  these  repeated  attempts  would  be 
made  by  the  computer,  not  the  dispatcher. 
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2.2  Driver  Perspective 

Vans  were  ridden  for  a  total  of  seven  hours  on  two  different  days  between  the  hours  of 
8:00  am  and  2:00  pm.  Observations  during  this  time  showed: 

•  The  drivers  often  had  to  radio  more  than  once  before  receiving  a  response  from  the 
dispatcher. 

•  Repetition  of  the  dispatcher’s  message  was  frequently  requested. 

•  The  vehicle  was  vacant  and  idle  multiple  times.  At  one  point,  a  driver  left  his  stop 
without  knowing  his  next  destination  and  had  to  turn  the  vehicle  around  upon 
receiving  his  next  trip  assignment. 

•  Calling  the  dispatcher  to  relay  pick-up/drop-off  information  did  not  necessarily  occur 
when  the  vehicle  was  stopped.  This  observation  is  mentioned  in  light  of  its  effect  on 
the  accuracy  of  trip  arrival  and  departure  times. 

Experiences  on  the  van  rides  prompted  the  distribution  of  a  survey  to  see  how  common 
these  observations  were  among  all  drivers.  The  survey  included  a  cover  letter  that  gave  a 
simple  explanation  of  MDT’s,  questions  about  current  operations,  and  questions  about 
driver  attitudes  toward  the  idea  of  MDT’s.  It  was  distributed  to  all  16  drivers,  and  13 
surveys  were  returned.  Appendix  B  contains  the  survey  questionnaire  and  the  compiled 
results. 

The  following  subsections  discuss  the  findings  of  this  survey. 

2.2.1  Multiple  Attempts  to  Reach  Dispatcher 

The  survey  revealed  that  the  driver  often  made  more  than  one  attempt  to  call  the 
dispatcher  before  receiving  response.  A  discussion  with  one  of  the  dispatchers  about  why 
this  was  so  showed  that: 

•  Drivers  can  only  hear  the  dispatcher,  not  the  other  drivers,  from  their  radios. 

Because  of  this,  they  may  be  attempting  to  call  in  while  unaware  that  another  driver  is 
talking. 

•  If  the  driver  calls  in  while  the  dispatcher  is  talking,  she  will  not  be  heard. 

•  Sometimes  a  driver  may  think  that  a  conversation  is  finished  based  on  what  she  hears 
from  the  dispatcher.  She  will  then  attempt  to  talk  over  the  ongoing  conversation  and 
fail  to  be  heard. 

•  If  two  drivers  call  in  at  the  same  time,  both  may  not  be  heard. 

•  If  a  driver  calls  in  during  another  radio  or  phone  conversation,  he  may  be  heard,  but 
the  dispatcher  may  not  be  able  to  respond  to  him. 

For  these  reasons,  multiple  call-outs  are  a  “fact  of  life”  in  a  voice  radio  communication 
system.  They  are  a  source  of  inefficiency,  so  it  would  be  helpful  to  alleviate  them. 

Here  are  the  responses  to  two  driver  survey  questions  regarding  the  number  of  call-in 
attempts  required  to  reach  a  dispatcher: 
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1.  I  usually  get  a  response  the  first  time  I  call  out  to  the  dispatcher. 

Disagree;  8  out  of  13 
Neutral:  lout  of  13 
Agree:  4  out  of  13. 

The  majority  do  not  usually  get  a  response  the  first  time  they  call  out  to  the  dispatcher 

2.  How  often  do  you  have  to  call  out  to  the  dispatcher  multiple  times  before  getting 
a  response? 

50%  of  the  time  or  more:  6  out  of  13 
25%  of  the  time  or  more;  9  out  of  13 
Rarely:  4  out  of  13 

The  majority  make  call  outs  25%  of  the  time  or  more. 

In  the  section  of  the  survey  provided  for  comments,  five  drivers  made  reference  to  heavy 
radio  traffic  and/or  difficulty  reaching  the  dispatcher. 

In  addition  to  the  driver  survey,  we  developed  a  Continuous-Time  Markov  Chain  model 
to  determine  the  percentage  of  the  time  drivers  reach  the  dispatcher  on  the  first  attempt. 
The  results  from  this  particular  problem  were  not  included  in  the  client  report  because  the 
model  made  several  simplifying  assumptions.  Nevertheless,  the  problem  is  an  interesting 
one,  and  it  is  outlined  in  Appendix  C.  Analysis  of  the  CTMC  model  indicated  that 
drivers  reach  the  dispatcher  upon  first  attempt  less  than  70%  of  the  time.  In  other  words, 
nearly  one  out  of  three  calls  to  the  dispatcher  require  multiple  attempts  in  order  to  gain 
response. 

These  results  confirm  the  original  observation  that  multiple  attempts  to  reach  the 
dispatcher  are  a  problem.  A  delay  in  reaching  the  dispatcher  could  cause: 

•  Delay  in  receiving  next  trip  information 

•  Delay  in  trip  execution  (i.e.,  late  arrivals) 

•  Inaccurate  pick-up/drop-off  time  information 

•  Less  attention  devoted  to  the  passenger  while  the  driver  is  on  the  radio. 

With  MDT’s,  the  issue  of  multiple  call  attempts  would  be  eliminated.  Drivers 
would  send  trip  information  by  using  a  short  keying  sequence  without  having  to 
wait  for  the  acknowledgment  of  the  dispatcher.  Information  about  the  driver ’s 
next  trip  would  most  likely  already  be  on  his  screen,  since  those  data  are  sent 
when  the  dispatcher  assigns  trips  to  vehicles.  The  driver  would  be  able  to  leave 
the  stop  right  away,  increasing  the  likelihood  of  arriving  to  the  next  stop  on 
time.  Trip  execution  time  stamps  would  be  related  to  the  time  the  driver  entered 
the  data,  rather  than  to  the  time  the  data  arrived.  Finally,  spending  less  time 
waiting  for  acknowledgment  on  the  radio  would  give  the  driver  more  freedom  to 
serve  the  customer. 
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2.2.2  Repetitions 


The  reasons  for  message  repetitions  were  discussed  in  Section  2.1  from  the  dispatcher’s 
perspective,  and  they  also  apply  to  the  driver’s  perspective.  The  results  from  this  survey 
question  on  this  topic  are: 


How  often  do  you  have  to  repeat  yourself  or  ask  the  dispatcher  to  repeat  herself 
because  a  message  was  unclear? 

50%  of  the  time  or  more:  7  out  of  1 3 

25%  of  the  time  or  more:  1 0  out  of  1 3 

Rarely:  3  out  of  1 3 

The  majority  of  drivers  have  to  repeat  themselves  25%  of  the  time  or  more. 

Repetitions  extend  the  average  length  of  a  radio  call,  which  increases  the  busy  time  of  the 
dispatcher  and  forces  the  driver  to  spend  less  time  with  the  customer. 

MDT’s  would  eliminate  the  need  for  the  driver  to  repeat  messages,  which  would 
decrease  dispatcher  busy  time  and  increase  the  amount  of  time  available  for  the 
customer  to  spend  with  the  passenger. 


2.2.3  Vacant  Vehicles 

Van  observation  revealed  that  drivers  usually  knew  their  next  destination  when  they 
reached  a  stop.  For  the  most  part,  the  dispatcher  informed  the  driver  of  two  or  three  trips 
at  a  time.  However,  from  time  to  time,  the  driver  had  a  vacant  vehicle  and  had  received 
no  instruction  on  where  to  go  next. 

In  this  situation,  a  driver  should  attempt  to  call  the  dispatcher  for  his  next  trip.  If  he  does 
so,  he  faces  the  multiple  call-out  issue.  If  he  does  not  choose  to  call,  the  dispatcher  will 
most  likely  be  vmaware  of  the  driver’s  “vacant  and  idle”  status.  In  both  the  vehicle  and 
the  dispatcher’s  booth,  the  study  identified  situations  in  which 

•  The  idle  driver  called  in,  and  the  dispatcher  was  not  aware  of  his  status. 

•  The  dispatcher  called  out  to  a  driver  who  had  not  called  in  and  discovered  that  her 
status  was  idle. 
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About  how  many  times  per  day  do  you  find  yourself  waiting  at 
a  stop  to  find  out  where  you  need  to  go  next? 
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Figure  5 


Figure  5  shows  that  the  majority  of  drivers  are  idle  and  vacant  between  1  and  6  times  per 
day.  Vacant  and  idle  vehicles  are  of  concern  because  they  lead  to  lower  average  trips  per 
hour  and  more  late  arrivals. 

With  MDT’s  in  place,  the  driver  would  be  aware  of  all  trips  that  had  been 
assigned  to  his  vehicle  up  until  that  point.  She  would  therefore  be  less  likely  to 
be  at  a  stop  waiting  to  find  out  where  to  go  next.  Of  course,  she  would  still  have 
to  wait  if  the  dispatcher  had  not  yet  assigned  any  more  trips  to  her  vehicle. 

During  one  van  ride,  the  driver  dropped  off  a  customer  at  1:31  pm.  At  1 :40  he  attempted 
to  call  the  dispatcher  for  his  next  trip.  After  receiving  no  response,  he  left  his  location. 
When  the  dispatcher  called  him  at  1 :44  with  his  next  trip  information,  he  had  to  turn 
around. 

This  situation  prompted  a  driver  survey  question  about  the  number  of  times  they  leave  a 
stop  under  similar  circumstances  during  the  day.  Twelve  out  of  thirteen  drivers  indicated 
that  they  did  sometimes  leave  a  stop  before  knowing  their  next  destination  during  the  day. 
Among  these,  the  indicated  average  number  of  occurrences  per  day  was  3.2. 

Leaving  a  stop  without  knowing  her  next  destination  can  force  the  driver  to  turn 
around.  This  wastes  time  and  resources.  With  MDT’s,  this  could  be  avoided 
since  drivers  would  almost  always  be  aware  of  their  next  trip  information. 


2.2.4  Attitudes  Toward  MDT’s 

If  CHT  decides  to  implement  an  MDT  system,  it  will  be  important  to  have  the  drivers’ 
support,  since  they  will  be  the  MDT  operators.  The  Minipass  computer-aided  dispatch 
system  has  only  been  in  place  since  December  of  1996,  and  both  dispatchers  and  drivers 
are  struggling  to  make  the  operational  transition.  In  light  of  this,  it  is  important  for  CHT 
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administrators  to  have  an  awareness  of  drivers’  attitudes  toward  the  idea  of  a  mobile  data 
system.  A  few  questions  in  this  survey  sought  to  find  out  what  drivers  thought.  Figures 
6,7,  and  8  illustrate  the  results. 


I  am  satisfied  with  the  way  driver-dispatcher  radio 
communications  currently  work. 


Strongly  Disagree  Neutral  Agree  Strongly 
Disagree  Agree 


Figure  6 


Figure  6  shows  that  7  out  of  1 3  people  expressed  some  level  of  dissatisfaction  with  the 
current  system.  Results  indicate  that  more  are  dissatisfied  than  satisfied;  however,  almost 
half  are  either  neutral  or  satisfied.  Although  driver  opinions  are  well-mixed  on  this  issue, 
they  lean  more  toward  dissatisfaction  with  the  way  radio  communications  work  now. 


With  the  appropriate  training,  1  think  1  would  be  comfortable 
with  the  idea  of  using  an  MDT  in  my  vehicle. 
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Figure  7 


Figure  7  reveals  that  none  of  the  drivers  who  responded  thought  that  he  would  be 
uncomfortable  with  an  MDT.  Ten  out  of  thirteen  expressed  some  level  of  agreement  with 
the  statement. 
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I  think  MDT's  are  a  good  idea. 
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Figure  8 


Figure  8  shows  that  this  statement  did  not  receive  as  much  positive  response  from  the 
drivers.  Although  7  out  of  13  still  expressed  their  agreement  with  the  notion  of  MDT’s 
being  a  good  idea,  2  drivers  strongly  disagreed.  The  management  should  be  aware  that 
these  sentiments  exist  among  some  of  the  drivers. 

In  the  course  of  this  research,  we  spoke  with  representatives  from  several  cities  that  have 
already  installed  similar  systems.  More  detailed  discussion  of  these  conversations  can  be 
found  in  Chapter  3.  Each  of  the  cities  we  contacted  indicated  that  its  drivers  had  a 
favorable  response  to  MDT’s. 


2.3  Reporting  Perspective 

City  representatives  we  spoke  with  indicated  that  reporting  capabilities  were  one  of  the 
most  significant  benefits  they  had  experienced  after  acquiring  MDT’s.  Reporting  is 
important  because  it  provides  administrators  with  the  tools  to  assess  operations  from 
several  standpoints.  These  include  cost-efficiency,  customer  service,  and  activity  level. 

Mr.  McClellan  mentioned  that  reporting  average  trip  length,  individual  trip  lengths, 
comparison  of  revenue  miles  vs.  total  miles,  average  trip  time,  individual  trip  times,  dwell 
times,  number  of  passengers  per  mile  or  hour,  and  on-time  vs.  late  trip  execution  times 
were  of  interest  to  CHT.  The  following  subsections  explain  how  MDT’s  would  aid  in 
generating  these  reports. 

2.3.1  Real-Time  Credibility 

If  a  no-show  customer  calls  to  find  out  why  she  was  not  picked  up  for  her  trip,  the 
dispatcher  currently  explains  that  she  was  not  there  on  her  pick-up  time,  and  that  drivers 
are  not  to  wait  more  than  three  minutes  for  a  passenger. 

With  MDT’s,  the  dispatcher  could  give  the  customer  more  specific  information, 
such  as  “Mrs.  Jones,  our  records  show  that  van  #707  arrived  at  10:03  and 
departed  at  1 0:06.  This  type  of  real-time  reporting  of  trip  data  lends  credibility 
to  the  dispatcher,  allowing  him  to  handle  customer  questions  quickly  and 
effectively. 
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2.3.2  Time  and  Mileage  Stamping 


At  present,  drop-offs  and  pick-ups  are  time-stamped  by  the  Minipass  CAD  software  when 
they  are  entered  into  the  computer.  However,  this  time  is  not  an  accurate  representation 
of  the  actual  trip  execution  time.  The  driver  reports  the  trip  by  voice,  and  the  dispatcher 
enters  that  trip  completion  at  some  point  afterward.  If  it  has  been  more  than  a  few 
minutes,  the  dispatcher  overrides  the  computer’s  time  stamp  and  enters  an  estimated 
completion  time.  The  dispatcher  may  have  to  ask  the  driver  for  an  estimated  completion 
time.  Figure  9  gives  a  pictorial  description  of  this  process. 


Figure  9  -  Recording  Trip  Stop  Times 


This  method  does  not  provide  reliable  trip  execution  times  for  reporting  purposes.  CHT 
charges  some  customers  based  on  time  spent  on  the  vehicle,  which  requires  accurate  trip 
completion  time  information.  In  addition,  CHT  has  committed  to  limiting  customer  trips 
to  60  minutes  when  possible.  Without  an  accurate  method  of  tracking  trip  lengths, 
however.  Chapel  Hill  does  not  have  a  way  of  measuring  its  performance  in  this  area. 
With  accurate  trip  length  reports,  CHT  may  even  be  able  to  commit  to  shorter  trip 
lengths. 

Since  MDT’s  are  accessible  to  the  driver,  they  would  be  an  excellent  tool  for 
accurate  trip  time  information.  When  a  driver  sends  a  precanned  message,  the 
MDT  automatically  attaches  the  time  to  the  other  trip  information.  As  Figure  9 
demonstrates,  an  accurate  time  would  only  rely  on  the  driver 's  prompt  entry  of 
the  stop  into  the  MDT.  Time  stamps  on  different  messages  such  as  “arrive  ”  and 
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“board”,  for  example,  would  also  allow  for  reports  on  dwell  time  (time  spent  at 
a  stop  before  customer  boards). 

Mileage  stamps  also  accompany  any  message  that  is  sent  by  ein  MDT  if  odometer  readers 
are  included  in  the  system.  Odometer  readers  are  a  relatively  inexpensive  option 
available  on  both  MDT’s  we  investigated.  Having  an  odometer  reading  at  every  stop 
would  allow  for  reporting: 

•  Average  trip  length 

•  Average  speed  of  the  vehicle 

•  Total  miles  traveled  by  vehicle 

•  Passengers  per  mile. 

There  is  currently  no  system  in  place  to  attempt  to  monitor  the  length  of  each 
trip.  Having  odometer  readers  on  MDT’s  would  add  to  CHT’s  reporting 
capabilities  in  this  manner.  It  would  also  eliminate  the  need  for  drivers  to  call 
in  their  starting  and  ending  mileage  each  day  for  the  dispatchers  to  enter  into 
the  Minipass  system  manually. 

2.3.3  Flexible  Data  Collection 

MDT’s  have  programmable  function  keys,  and  would  be  able  to  provide  data  collection 
capabilities  for  door  cancellations,  no-shows,  boardings,  alightings,  and  similar  events 
indicated  by  the  client.  This  flexibility  would  allow  for  the  collection  of  information  that 
would  be  of  particular  interest  to  CHT. 
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2.4  Customer  Perspective 


Preceding  sections  of  Chapter  2  have  provided  a  great  deal  of  analysis  and  discussion  of 
the  possible  impact  of  MDT’s  on  CHT’s  operations.  This  has  been  approached  from  the 
dispatcher,  driver,  and  reporting  perspectives.  Many  of  the  potential  gains  can  be  viewed 
from  another  perspective  -  that  of  the  customer. 

Based  on  the  findings,  the  customer  will  be  affected  in  the  following  ways  if  MDT’s  are 
introduced: 

1 .  Reduced  dispatcher  workload  would  provide  more  time  for  her  to  focus  on  making 
good  choices  for  assignment  of  trips  to  vehicles.  Better  dispatching  would  result  in 
more  timely  service. 

2.  Reduced  radio  traffic  would  lessen  the  need  for  dispatchers  to  answer  radio  calls 
while  on  the  phone  or  put  the  customer  on  hold  to  converse  with  a  driver.  This  would 
have  the  effect  of  shortening  the  time  a  customer  stays  on  the  phone.  Shorter  phone 
calls  would  also  reduce  the  likelihood  of  receiving  a  busy  signal  when  calling  in. 

3.  MDT’s  would  reduce  the  dispatcher’s  interaction  with  Minipass.  She  would  only  use 
it  to  dispatch  and  book  trips.  Again,  this  lessened  dispatcher  activity  would  allow  for 
a  more  customer-oriented  level  of  operations. 

4.  Reducing  the  time  a  driver  must  spend  trying  to  relay  a  trip  stop  message  translates 
into  increasing  his  ability  to  focus  on  the  customer. 

5.  MDT’s  would  allow  the  driver  to  see  her  next  trip  without  waiting  for  the  dispatcher 
or  having  to  turn  around.  This  would  provide  more  timely  service  for  the  customer. 

6.  Reporting  that  indicates  average  customer  trip  time  will  allow  administrators  to 
monitor  performance  more  accurately.  If  customers  are  staying  on  vehicles  for  too 
long,  this  will  be  clear  from  trip  time  data,  and  CHT  will  be  able  to  take  steps  to 
improve  the  situation. 

7.  Accurate  trip  time  and  mileage  reporting  will  enable  CHT  to  charge  clients  correctly 
for  services  rendered. 
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2.5  Summary 


The  findings  included  in  this  chapter  indicate  that  MDT’s  will  improve  CRT’s  paratransit 
operations  in  a  variety  of  ways.  These  include: 

•  Reducing  the  busy  time  of  the  dispatcher 

•  Reducing  the  time  associated  with  dispatcher  data  entry 

•  Eliminating  the  current  problems  of  radio  call  repetitions  and  multiple  call-outs 

•  Eliminating  the  current  problem  of  multiple  driver  attempts  to  reach  the  dispatcher 

•  Reducing  the  occurrence  of  vehicles  being  idle  or  vacant 

•  Improving  real-time  reporting  credibility 

•  Improving  reporting  capabilities  via  time  and  mileage  stamping 

•  Providing  flexibility  in  data  collection 

•  Improving  service  provided  to  customers  calling  dispatcher 

•  Improving  service  provided  to  passengers  during  their  trips. 

As  this  chapter  has  shown,  the  benefits  associated  with  MDT’s  will  provide  good 
solutions  to  many  of  the  problems  currently  observed  in  CRT’s  paratransit  operations. 
These  benefits  should  be  weighed  along  with  the  costs  explored  in  Chapters  3  and  4  in 
order  for  CRT  to  make  a  decision  about  adding  this  technology. 
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CHAPTERS: 

MDT  Implementation 


3.1  Investigation  of  MDT Implementation 

In  addition  to  investigating  the  effects  of  MDT’ s  on  current  operations,  the  study  included 
research  concerning  what  steps  CHT  would  need  to  take  to  implement  MDT’s.  The 
information-gathering  process  involved  interaction  with  many  sources,  including  state 
transportation  and  telecommimications  representatives,  several  sales  representatives  from 
Trapeze,  and  many  MDT  vendor  representatives. 

Ms.  Debbie  Collins,  of  the  Institute  for  Transportation  Research  and  Education  (ITRE)’s 
Public  Transportation  Program,  provided  some  initial  contacts.  She  suggested  contacting 
Mentor  Engineering  and  GMSI,  Inc.  She  also  recommended  talking  to  representatives  of 
public  transportation  systems  in  Charlotte,  NC,  Winston-Salem,  NC,  Minneapolis,  MN,  and 
Lakeland,  OH,  due  to  their  involvement  with  MDT’s. 

These  initial  calls  led  to  many  additional  points  of  contact.  Each  conversation  provided  new 
facts  about  MDT  implementation.  An  analysis  of  the  compiled  information  gathered  in  these 
conversations  indicated  that  adding  an  MDT  system  would  require  three  actions  for  CHT; 

•  Action  1:  Acquire  some  type  of  communications  network  to  transmit  data 

Without  an  adequate  communications  network  to  transmit  data  from  the  vehicle  to  the 
dispatcher’s  computer,  the  MDT  itself  is  useless.  Clients,  MDT  vendors,  and  Trapeze 
representatives  all  stressed  this  point.  A  communications  network  must  be  able  to  handle 
all  data  transmitted  from  dispatcher  to  driver  (or  vice  versa)  efficiently  if  MDT’s  are  to 
have  a  positive  impact  on  operations. 

•  Action  2;  Negotiate  a  contract  with  Trapeze  to  interface  Minipass  with  MDT’s 

With  MDT’s,  the  dispatcher  does  not  have  to  enter  trip  data  because  that  information  is 
transferred  directly  from  the  driver  to  the  central  computer.  This  requires  communication 
between  MDT  software  and  the  dispatching  software.  CHT  would  need  to  have  a 
contract  with  Trapeze  Software  Group  to  handle  the  MDT-Minipass  interface. 

•  Action  3:  Choose  an  MDT  vendor  and  negotiate  a  contract  with  that  company. 

Clearly,  CHT  needs  to  choose  a  company  to  provide  its  MDT’s.  This  company  should 
provide  a  high-quality  product  with  adequate  functionality  at  a  low  cost,  it  would  also  be 
appropriate  to  consider  company  size,  background,  location,  and  experience  in  paratransit 
operations. 

Chapter  3  describes  the  details  associated  with  each  action.  Appendix  D  contains  phone 
numbers  for  contacts  referred  to  in  Chapters  3  and  4. 
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3.2  Action  1:  Communications  Network  Acquisition 

3.2.1  Four  Options 

Data  are  transmitted  between  MDT’s  and  the  dispatcher’s  central  computer  via  a 
communications  network.  The  MDT  vendors  that  were  considered  have  designed  their 
products  to  interface  with  several  different  types  of  communications  networks.  In  order  to 
implement  MDT’s,  CHT  would  need  to  have  a  reliable  way  of  transmitting  data.  The 
four  available  options  that  we  found  are: 

Option  1:  Use  current  radio  channel  to  transmit  both  voice  and  data. 

CHT  currently  has  one  450  MHz  UHF  radio  channel,  call  sign  KAG662,  which  is  used 
for  voice  communication  between  dispatchers  and  fixed  route  and  paratransit  vehicles. 

Although  it  would  be  possible  to  transmit  both  voice  and  data  using  KAG662,  MDT 
vendor  representatives  did  not  recommend  this  approach.  The  reason  for  this 
recommendation  was  that  the  voice  traffic  generated  by  fixed-route  vehicles,  along  with 
the  small  amount  of  paratransit  voice  traffic  not  alleviated  by  MDT’s,  would  probably 
cause  delays  in  data  transmission. 

Both  Winston-Salem  Transit  Authority  (Winston-Salem,  NC)  and  Everett  Transit 
(Everett,  WA)  confirmed  this  concern.  Each  had  tried  to  use  the  same  channel  for  voice 
and  data,  and  each  experienced  significant  transmission  delays  that  negatively  affected 
operations.  Both  were  forced  to  seek  other  communications  alternatives  after  their  MDT 
systems  were  operational. 

Option  2:  Gain  another  UHF  channel,  and  designate  it  to  transmit  data  only. 

Consultation  with  Mr.  Dyke  Hostettler,  NC  State  Frequency  Coordinator,  confirmed  that 
CHT  would  be  able  to  acquire  a  second  UHF  channel.  This  would  allow,  CHT  to  use  one 
channel  for  voice  and  the  other  for  data  in  order  to  facilitate  quick  message  transmission. 
Since  the  cost  associated  with  this  action  is  low  compared  with  other  alternatives,  this 
would  be  of  great  benefit  to  CHT.  Although  UHF  channels  are  limited,  Mr.  Hostettler 
conducted  a  frequency  search  which  indicated  that  the  frequency  452.7  MHz  would  be 
available  to  CHT.  Appendix  E  contains  the  search  information. 

The  cost  associated  with  acquiring  a  second  UHF  channel  would  be  minimal.  According 
to  Mr.  Hostettler,  a  one-time  FCC  license  fee  would  be  under  $300.  Mobile  radio 
equipment  could  be  used  to  switch  from  one  channel  to  another.  This  would  involve 
changing  from  hand-held  to  mobile  radios  in  paratransit  vehicles.  Alternatively,  CHT 
may  prefer  to  have  two  radios  in  each  vehicle  in  order  to  allow  for  continued  data 
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transmission  even  while  the  voice  channel  is  being  used.  Three  comments  on  the  driver 
survey  also  indicated  that  they  like  using  hand-held  units  for  voice  radio. 


Option  3:  Use  a  state-supported  800  MHz  mobile  data  trunked  radio  system. 

A  trunked  radio  system  is  large  mobile  data  infrastructure  which  allows  several 
subscribers  to  transmit  large  amounts  of  data  very  quickly.  The  system  is  managed  by 
very  fast  switching  equipment.  This  option  would  require  CHT  to  purchase  a  $2200 
modem  for  each  vehicle. 

The  trunked  network  is  designed  to  send  large  and  complex  amounts  of  information,  such 
as  criminal  records  for  the  North  Carolina  State  Highway  Patrol.  .Mr.  Hostettler,  who  is 
also  the  coordinator  for  this  system,  indicated  that  a  second  UHF  channel  would  be  more 
appropriate  and  cost-effective  for  CHT. 

Option  4:  Use  cellular  digital  packet  data  (CDPD)  technology. 

CDPD  allows  data  packets  to  be  transmitted  over  idle  portions  of  a  cellular  voice 
network.  It  could  be  provided  by  standard  cellular  providers.  It  would  require  a  CDPD 
modem  device  for  each  vehicle,  a  host-end  message  router,  and  would  involve  monthly 
charges  based  on  amount  of  data  transmitted. 

3.2.2  Recommendations  for  Accomplishing  Action  1 

Agreement  among  current  clients,  MDT  vendors,  and  Trapeze  indicates  that  attempting  to 
put  both  voice  and  data  on  one  channel  would  be  unwise.  The  options  of  using  a  trunked 
radio  system  or  CDPD  are  significantly  more  costly  than  simply  acquiring  a  second  UHF 
channel.  Since  a  second  channel  is  available,  the  recommended  option  is  to  acquire  it 
and  designate  it  specifically  for  data  transmission. 

If  CHT  decides  to  add  MDT’s,  we  recommend  that  it  first  acquire  this  channel.  UHF 
frequencies  are  limited,  and  continued  availability  cannot  be  guaranteed. 

A  second  radio  channel  could  be  accommodated  by  switching  back  and  forth  on  current 
radios  or  by  putting  two  radios  on  each  vehicle.  MDT  vendors  will  usually  conduct  a 
radio  evaluation  to  help  the  client  decide  how  to  configure  radios  in  its  vehicles.  Mr. 
Dean  Richardson,  regional  sales  representative  from  Trapeze,  also  suggested  that  CHT 
consider  inviting  an  independent  radio  consultant  to  evaluate  the  adequacy  of  its  current 
system  before  MDT  implementation.  He  suggested  that  this  initial  investment  could  save 
CHT  in  the  long  run.  Mr.  Richardson  recommended  Larry  Sparks,  of  Sparcoms 
Corporation  in  Cincinnati,  Ohio.  Mr.  Sparks  is  serving  as  the  radio  consultant  for 
Winston-Salem  Transit  Authority. 
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3.3  Action  2:  Contract  with  Trapeze 


3.3.1  Three  Issues 

A  contract  with  Trapeze  is  necessary  to  achieve  the  needed  interface  between  Minipass 
and  the  MDT  software.  This  contract  would  cover  the  license  for  the  interface  itself, 
engineering,  and  travel  expenses.  Three  issues  arise  when  considering  this  contract. 

Issue  1:  This  contract  requires  CHT  to  use  Minipass  CAD  software. 

The  cost  to  interface  is  about  half  of  the  total  cost  of  adding  MDT’s,  which  implies  that 
adding  MDT’s  requires  a  financial  commitment  to  the  Minipass,  as  well.  If  CHT  ever 
decides  to  change  to  new  dispatching  software,  a  new  MDT  interface  contract  would  be 
required.  CHT  should  recognize  its  long-run  commitment  to  the  use  of  Minipass  if  it 
decides  to  make  an  interface  contract  with  Trapeze, 

Issue  2:  CHT  would  be  the  first  system  to  interface  MDT’s  with  Minipass. 

Several  cities  have  interfaced  MDT’s  with  Pass,  another  CAD  software  package  made  by 
Trapeze.  Since  Minipass  is  essentially  Pass  with  several  options  switched  off,  Mr.  Don 
Christianson,  MDT  Project  Manager  for  Trapeze,  indicated  that  the  Minipass-MDT 
interface  engineering  would  be  similar  to  that  of  Pass.  Appendix  F  contains  the  details  of 
this  option. 

On  the  other  hand,  Mr.  Tom  Juhnke  of  South  West  Metro  Transit  (Minneapolis,  MN) 
indicated  significant  concern  about  CHT  being  the  first  to  have  this  type  of  interface. 
South  West  Metro  Tran  was  the  first  to  have  a  Pass-MDT  interface,  and  experienced  a 
great  deal  of  initial  difficulty.  He  suggested  that  a  contract  with  Trapeze  include  a 
commitment  for  an  on-site  representative  for  an  extended  period  of  time  until  the  system 
is  running  smoothly. 

Issue  3:  A  Minipass-MDT  interface  contract  would  rule  out  the  possibility  of 
Automated  Vehicle  Locator  Technology. 

Originally,  CHT  was  interested  in  the  possibility  of  including  Global  Positioning 
System/ Automated  Vehicle  Locator  technology  in  a  mobile  data  system.  However, 
Minipass  does  not  allow  for  this,  since  it  has  no  mapping  capability.  If  CHT  desires  AVL 
capability,  it  should  upgrade  to  Pass  CAD  software  (or  another  comparable  package) 
before  pursuing  an  MDT  interface  contract. 

3.3.2  Contract  Costs 

Mr.  Robert  Dukes,  Vice  President  of  Sales  at  Trapeze,  provided  a  cost  estimate  of  an 
MDT  interface  contract  between  CHT  and  Trapeze.  The  cost  breakdown  is  listed  here. 
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•  Interface  license  fee:  $10,000 

•  20-23  days  of  in-house  and  on-site  engineering:  $  1 7,000 

•  Airfare  and  travel  expenses:  $  5,000 

•  After  first  year,  annual  maintenance  fee:  $  2,000 

Total  initial  cost:  $32,000 

Total  annual  maintenance  cost:  $  2,000 


3.3.3  Recommendations  for  Accomplishing  Action  2: 

CHT  should  maintain  contact  with  Mr.  Rob  Dukes  and  Mr.  Dean  Richardson,  Trapeze 
sales  representative  for  North  Carolina,  to  negotiate  these  costs.  Additionally,  CHT 
should  consider  the  three  issues  presented  in  Section  3.3.1  before  pursuing  a  contract  with 
Trapeze. 


3.4  Action  3:  Choosing  an  MDT  Vendor 

The  third  part  of  implementing  an  MDT  system  is  choosing  the  MDT  vendor. 
Consideration  must  be  given  to  the  company  background,  location,  and  experience,  as 
well  as  product  functionality  and  costs.  Costs  are  associated  with: 

1 .  MDT  hardware  -  includes  the  unit  itself,  odometer  reader,  vehicle  mount,  cabling. 

2.  Host-End  needs  -  includes  system  software,  radio  modem  for  host  computer,  and  a 
PC  where  MDT  software  will  be  installed. 

3.  Engineering  costs  -  includes  on-site  and  in-house  engineering  and  travel  expenses. 

4.  Service  agreements  -  includes  initial  warranty,  extended  warranty,  and  on-going 
maintenance  and  support. 

Due  to  the  amount  of  information  and  level  of  detail  involved  in  making  this  decision, 
discussion  of  Action  3  is  covered  in  a  separate  chapter.  Chapter  4  investigates  and 
compares  MDT  vendors,  revealing  that  Mentor  Engineering  is  the  strongest  choice  for 
CHT.  It  includes  detailed  cost  information,  as  well. 
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3.5  Summary 


Chapter  3  determined  three  actions  which  CHT  would  need  to  take  in  order  to  add 
MDT’s  to  its  system.  The  recommendations  for  accomplishing  each  of  these  actions  as 
discussed  here  are: 

Action  1:  Take  early  action  to  acquire  a  second  UHF  channel  to  be  used  only  for  data 
transmission.  Consider  using  a  radio  consultant  to  help  determine  the  best  way  to  use 
radio  equipment  for  these  two  channels  in  the  vehicles. 

Action  2:  Negotiate  an  MDT  Minipass  interface  contract  with  Trapeze  with  an 
understanding  of  the  three  issues  presented  in  Section  3.2.1.  Maintain  contact  with  Mr. 
Rob  Dukes  and  Mr.  Dean  Richardson  to  do  this. 

Action  3:  Choose  Mentor  Engineering  as  the  MDT  vendor.  More  detailed 
recommendations  for  this  action  can  be  found  in  Chapter  4. 

If  Mentor  were  selected,  the  total  initial  cost  of  MDT  implementation  as  described  here 
would  be  about  $66,500,  followed  by  costs  of  about  $4,500  per  year  for  maintenance  and 
upgrades.  This  estimate  does  not  include  radio  consultant  or  additional  radio  hardware 
costs. 
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Chapter  4: 
MDT  Vendors 


4.1  How  Vendors  Were  Considered 


If  CHT  chooses  to  implement  this  mobile  data  system,  it  will  need  to  choose  an  MDT 
vendor.  This  study  investigated  several  transportation  technology  and  mobile  data 
communications  companies.  Information  reflected  here  comes  from  multiple  phone 
surveys  of  company  sales  representatives  and  client  system  representatives,  along  with 
product  information  and  written  correspondence. 

In  addition  to  the  cost  of  the  product,  there  were  other  factors  which  needed  to  be 
considered  in  choosing  an  MDT  vendor.  These  included  the  company’s  background,  its 
experience  with  mobile  data  communications  in  a  paratransit  context,  and  its  experience 
working  with  Trapeze  produets.  Clients  who  had  systems  similar  to  that  of  CHT  were 
asked  about  their  choice  and  their  overall  satisfaction  with  the  product. 

Sections  4.2  and  4.3  deal  with  GMSI  and  Mentor  Engineering,  two  companies  with 
products  that  would  suit  the  needs  of  CHT.  Each  section  addresses  the  company  in  terms 
of  background,  experience,  product,  and  clients.  Section  4.4  lists  other  companies  which 
were  considered.  Section  4.5  summarizes  reasons  for  the  vendor  recommendation  offered 
here. 


4.2  GMSI,  Inc. 

4.2.1  About  the  Company 

GMSI,  Inc.  is  a  mobile  data  communications  company  and  systems  integrator.  It  has 
been  installing  systems  for  eighteen  years,  and  has  55  sites  established  worldwide  in 
Canada,  the  U.S.,  the  U.K.,  Europe,  Asia,  Australia,  and  South  America.  Among  these 
sites,  there  are  25,000  MDT’s  up  and  running.  It  has  experience  with  systems  in  the  taxi, 
courier,  service,  trucking,  emergency  service,  transit,  and  paratransit  industries.  GMSI’s 
parent  company,  Geotek,  is  a  wireless  communications  service  provider. 

GMSI  has  sixty-five  employees  and  six  offices  worldwide,  the  closest  of  which  is  Fort 
Myers,  FL.  The  sales  representative  we  worked  with  was  Mr.  Greg  Davis. 

4.2.2  Experience  in  Paratransit  Operations 

GMSI  has  a  great  deal  of  experience  in  the  taxi  industry,  which  has  many  parallels  with 
the  demand-responsive  aspects  of  the  paratransit  industry.  However,  the  company  has 
only  recently  begun  to  implement  systems  for  paratransit  operations.  It  currently  has  five 
contracts  with  paratransit  operations,  two  of  which  are  up  and  running.  These  two  are 
with  Winston-Salem  Transit  Authority  (Winston-Salem,  NC)  and  the  Potomac  and 
Rapahonic  Transit  Commission  (PRTC;  near  Washington,  DC). 
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Since  the  system  at  the  Winston-Salem  Transit  Authority  was  part  of  a  test  program, 
MDT’s  were  placed  on  only  three  vehicles.  They  are  interfaced  with  Trapeze’s  Pass 
CAD  software.  Winston-Salem  has  just  signed  a  contract  to  put  MDT’s  on  the  remainder 
of  its  vehicles. 

At  PRTC,  MDT’s  are  installed  and  working,  but  they  are  not  currently  being  used.  This 
is  due  to  a  delay  in  Trapeze  ’s  implementation  of  a  new  Windows-based  CAD  system. 

Only  three  of  GMSI’s  MDT’s  are  currently  operating  in  a  paratransit  context  with 
Trapeze  software  interface.  Several  more  are  under  contract,  but  it  is  clear  that  GMSI’s 
primary  experience  is  not  in  the  paratransit  industry. 

4.2.3  The  Product 

The  GMSI  product  for  CHT  to  consider  is  the  Paratransit  Vehicle  Information  System 
(PVIS).  PVIS  provides  integration  with  CAD  software,  MDT’s,  and  the  radio  system. 
PVIS  is  a  multitasking  system  -  i.e.,  it  can  send  different  messages  from  the  central 
computer  to  several  vehicles  at  one  time.  Essentially,  GMSI  would  provide  a  system 
that: 

•  Communicates  with  Minipass  to  gain  dispatching  information  and  update  trip 
performance  information 

•  Communicates  with  vehicle  MDT’s  via  radio  to  send  upcoming  trip  information  and 
to  collect  trip  performance  data 

•  Produces  management  reports. 

GMSI’s  mobile  data  terminal  is  called  MDT  4100  Series  -  Status  II.  The  MDT’s 
specifications  are  included  on  the  following  page.  Appendix  G  includes  a  detailed 
description  of  the  MDT  requirements  taken  from  a  sample  Request  for  Proposal  from 
GMSI.  Important  aspects  of  the  MDT  are: 

•  The  display  and  keypad  are  integrated  into  an  L-shaped  unit. 

•  The  display  is  back  lit,  has  full  character-set  capability  including  bold,  underlined, 
double-height,  and  blinking  characters,  and  has  six  forty-character  lines. 

•  The  keypad  is  back  lit,  has  hard-coded  (programmed  by  vendor)  and  soft-coded 
(menu-driven)  keys,  and  a  numeric  keypad. 

•  The  MDT  is  capable  of  collecting  data  associated  with  driver  log-on,  log-off,  site 
arrival,  site  departure,  rider  boarding,  rider  alighting,  rider  call-out,  rider  no-show, 
door  cancellation,  and  fares  paid. 

•  The  MDT  sends  data  at  4800  baud,  has  a  32-bit  processor,  and  has  128K  of  RAM. 
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4.2.4  Paratransit  Clients 


Both  of  GMSI’s  operational  clients  were  surveyed.  Although  PRTC  mentioned  a 
sometimes  slow  reaction  to  customization  issues  and  Winston-Salem  has  had  trouble  with 
the  Pass-MDT  interface,  discussions  revealed  a  generally  positive  reaction  to  the 
company  and  its  product.  The  following  page  summarizes  conversations  with 
representatives  from  these  two  systems. 


34 


Figure  10  -  Summary  of  Conversations  with  Two  GMSI  Clients 


m 


takes  a  few  seconds.. 


4.2.5  Contract  Costs 


Mr.  Davis  initially  quoted  system  costs  over  the  telephone.  In  order  to  confirm  a  correct 
estimate,  costs  were  summarized  in  the  following  spreadsheet.  This  was  then  confirmed 
and  edited  by  Mr.  Davis,  and  he  indicated  that  these  reflected  all  costs  that  would  be 
involved  in  a  GMSI  contract. 

Total  initial  cost:  $47,170 

Total  additional  annual  cost:  $2,902 

Figure  1 1  on  the  following  page  contains  a  breakdown  of  the  system  costs  for  GMSI’s 
products.  Costs  are  broken  down  into  vehicle  hardware,  host-end  needs,  labor,  initial 
service  agreement,  and  annual  service/maintenance  costs. 
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Vehicle  Hardware 

Per  Unit 

Total 

MDT  Cost 

Odometer  Readers 

$100 

$800 

MDT  Mounts 

$35 

$280 

Driver  Manuals 

$4 

$80 

Shipping  and  Duty 

$750 

Total 

$11,510 

Hos^End  Needs . 

MDT  Software 

MDT  Startup  Program 

$560 

Radio  Modem  for  Host  Computer 

$1,500 

PC  -  MDT  Server 

$2,500 

Total 

$6,060 

‘erOat::” 

®TotaL^ 

In-House  Engineering  (20  Days) 

$500 

$10,000 

On-Site  Engineering  (18  Days) 

$500 

$9,000 

Travel/Living  Expenses  (18  Days) 

$350 

$6,300 

Misc. 

$3,000 

Total 

$28,300 

t-/;?iv^:J¥in;Sefvice  Agreements -■£ 

1-yr.  warranty 

$800 

Modem  for  repairs 

$500 

Buy  5%  Overages 

$1,200 

Total 

$1,300 

Grand-JotaMr  -'r-s.  t; $47,170 


.'Service  Agreements>  Annual 

f  Per;,  y  nit:;SltTotal;  ^ 

MDT  Maintenance 

$100  $802 

24-hr.  Service 

$2,100 

|iTeariigS§|[viceiTotal^il^;:lh:?sifc^ 

.^:iu::;:>;$2.902: 

Figure  11 
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4.3  Mentor  Engineering 

4.3.1  About  the  Company 

Mentor  Engineering  is  a  Mobile  Data  Solutions  company  which  has  been  implementing 
mobile  data  systems  for  eight  years.  It  is  smaller  than  GMSI,  with  only  20  employees 
and  one  office.  It  currently  has  installed  over  50  systems  worldwide  in  the  U.S.,  Canada, 
and  Mexico.  Mentor  has  experience  in  the  paratransit,  oil/gas  production,  limousine, 
taxi,  newspaper  distribution,  towing,  rock  quarry,  utility,  transit,  and  delivery  vehicle 
industries. 

Mentor  is  based  in  Calgary,  Alberta,  Canada.  All  sales,  engineering,  and  warranty  repair 
efforts  are  conducted  from  this  office.  We  worked  with  Mr.  Brent  Freer,  a  sales 
representative  there. 

4.3.2  Experience  in  Paratransit  Operations 

Mentor  currently  has  9  paratransit  operations  up  and  running.  It  has  contracts  underway 
with  3  more.  Of  these,  5  have  fewer  than  twenty  vehicles  and  8  are  interfaced  with 
Trapeze  dispatching  software.  Contacts  and  system  descriptions  were  provided  by 
Mentor  and  are  included  in  Appendix  H. 

Mentor’s  experience  with  paratransit  operations  is  broad,  considering  the  newness  of  the 
field.  One  of  its  clients.  South  West  Metro  Tran,  has  had  MDT’s  on  its  22-vehicle  fleet 
for  2  years.  This  experience  will  be  beneficial  to  CHT  if  it  decides  to  work  with  this 
vendor. 

4.3.3  The  Product 

Mentor’s  product  is  called  the  Express  Plus  Mobile  Data  System.  Its  primary  feature  is 
the  Express  Plus  Mobile  Data  Terminal.  It  also  includes  XGate  software,  which: 

•  Communicates  with  Minipass  to  gain  dispatching  information  and  update  trip 
performance  information 

•  Communicates  with  vehicle  MDT’s  via  radio  to  send  upcoming  trip  information  and 
to  collect  trip  performance  data 

•  And  produces  management  reports. 

This  product  is  quite  comparable  to  GMSI’s  product.  The  Express  Plus  MDT  has  the 
following  characteristics: 

•  The  display  and  keypad  are  integrated  into  small  rectangular  unit. 

•  The  display  is  transflective  (for  bright  sunlight  viewing)  and  back  lit,  has  full 
character-set  capability,  and  has  four  forty-character  lines. 
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•  The  membrane  keypad  has  no  moving  parts,  is  back  lit,  has  hard-coded  (programmed 
by  vendor)  and  soft-coded  (menu-driven)  keys,  and  a  numeric  keypad. 

•  The  MDT  has  LED  indicators  for  messages  and  to  indicate  radio  channel  quality. 

•  The  MDT  is  capable  of  collecting  data  associated  with  driver  log-on,  log-off,  site 
arrival,  site  departure,  rider  boarding,  rider  alighting,  rider  call-out,  rider  no-show, 
door  cancellation,  and  fares  paid. 

•  The  MDT  sends  data  at  1200  baud,  has  an  8-bit  processor,  and  has  32K  of  RAM. 

Mr.  Freer  indicated  that  the  best  feature  of  this  MDT  is  its  functional  flexibility.  Mentor 
is  interested  in  provided  a  custom  fit  to  CRT’s  MDT  needs.  For  example,  Mr.  Freer  said 
that  engineers  would  be  able  to  program  the  MDT  to  capture  driver  switches  on  the  same 
run. 

Appendix  I  contains  technical  specifications  for  the  Express  Plus  System  provided  by 
Mentor. 

4.3.4  Paratransit  Clients 

Discussions  with  some  of  Mentor’s  clients  revealed  an  overall  positive  reaction  to  the 
company  and  its  product.  Three  small  paratransit  systems,  all  with  Pass  dispatching 
software,  were  surveyed.  Also,  Charlotte,  NC’s  system  was  contacted  regarding  its 
recent  contract  with  Mentor. 

The  following  pages  summarize  conversations  with  four  of  Mentor’s  client  systems. 
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Initially  MDT’s  on  shared  voice  radio  frequency,  but  this  was 
problematic;  in  process  of  changing  to  trunked  system. 


4.3.5  Contract  Costs 


Mentor  provided  a  system  quote  that  is  included  in  Appendix  J.  In  order  to  more  easily 
compare  this  quote  with  GMSI’s  costs,  the  information  was  reorganized  into  a  cost 
spreadsheet  similar  to  that  presented  for  GMSI  in  section  4.1.5.  The  total  contract  costs 
are  significantly  lower  for  Mentor  than  GMSI.  The  largest  portion  of  this  difference  can 
be  accounted  for  in  engineering  costs.  Mentor  will  be  able  to  implement  the  same  system 
with  about  $10,000  less  in  engineering  costs. 

Total  initial  cost:  $34,034 

Total  additional  annual  cost:  $2,495 

Figure  14  on  the  following  page  contains  a  breakdown  of  the  system  costs  for  Mentor’s 
products.  Costs  are  broken  down  into  vehicle  hardware,  host-end  needs,  labor,  initial 
service  agreement,  and  annual  service/maintenance  costs. 
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Vehicle  Hardware 

Per  Unit 

Total 

MDT  Cost 

$1,200 

$9,600 

Odometer  Readers 

$89 

$712 

MDT  Mounts 

$65 

$520 

Cabling  for  MDTs 

$69 

$552 

Total 

$11,384 

®S^P€HipstiEndlNeeas^ 

Xgate  PC  (Preconfigured) 

$3,950 

Xgate  Software  License 

$1,400 

2  Master  Communications  Controllers  $1,895 

MCC  Install  Kit 

$150 

Total 

$9,290 

-^#''lJf^■':FerDay'^iS 

ITbtalKv-i 

On-site  engineering  (2  Weeks) 

$10,000 

1-2  hrs.  installation  per  vehicle 

$320 

$1,600 

Total 

$11,600 

'>?:/*SecviceV\greements^' 

;Total  r ; 

5-year  MDT  Warranty 

$220 

$1,760 

Total 

$1,760 

|!Grand^tal£S?p;;A3t;;';;n^ 

i$34i034| 

f'';TS^'>fTr'""^^f?*Service*Agreer 

nehtsrilAhnualjS''.5:g?? 

XGate  Maintenance 

$2,495 

|^arly^Seryice;Tdtal®f|®i-i;|;: 

4$2;495 

Figure  14 
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4.4  Other  Companies 


The  study  considered  other  transportation  management  and  mobile  data  companies.  They 
are  listed  here. 

1.  IRD  -  Teleride.  Inc. 

•  Division  of  International  Road  Dynamics,  Inc. 

•  Sales  Representative:  Raymond  Gleim 

IRD  Teleride  is  a  Fleet  Management  and  Transit  Systems  company.  Its  product, 
TransView  3.2,  takes  a  “turnkey”  approach  to  paratransit  fleet  management.  It 
features  CAD  software,  an  automated  voice  answering  system,  MDT’s  and  Global 
Positioning  System  (GPS)  capabilities.  The  system  is  Windows-NT  based,  and  it 
relies  upon  CDPD  communications.  There  are  two  up  and  running  in  Canada. 
Eight  more  contracts  have  been  signed,  two  of  which  are  in  the  U.S. 

IRD’s  MDT  is  only  one  aspect  of  its  whole  system.  The  MDT  itself  is  simple  -  it 
has  no  numeric  keypad,  and  no  programmable  function  keys.  Its  hard-coded  pick¬ 
up,  drop-off,  and  no-show  functions.  The  TransView  brochure  explains  that  the 
system  is  capable  of  interfacing  with  other  MDT’s.  Mentor’s  Express  Plus  MDT 
is  the  only  one  of  these  mentioned  in  this  context. 

IRD’s  primary  product  is  not  the  MDT,  but  the  company  does  seem  to  have  a 
good  turnkey  product.  This  company  would  be  a  good  option  if  CHT  were 
starting  from  scratch.  Since  CHT  already  has  CAD  software  and  is  looking  for  a 
high-quality  MDT  to  augment  this  system,  IRD  is  not  a  good  choice. 

2.  Transportation  Management  Solutions.  Inc. 

•  Subsidiary  of  Ra)^heon  E-Systems,  in  Linthicum,  MD 

•  Sales  Representative:  Mark  Krueger 

TMS  is  a  large  supplier  and  integrator  of  products  for  fleet  management.  Its 
product,  Fleet-Trac,  is  marketed  as  a  CAD/ Automated  Vehicle  Location  (AVL) 
system.  (AVL  uses  global  positioning  technology  to  track  the  location  of 
vehicles.)  This  system  involves  MDT’s,  but  TMS  does  not  actually  produce 
them.  In  fact,  the  company  uses  Mentor’s  Express  Plus  MDT  for  this  aspect  of 
the  system. 

TMS  does  not  offer  ein  MDT  product  to  be  compared  with  the  others  presented 
here.  Since  CHT  already  has  Minipass  for  its  CAD  system,  the  type  of  “whole 
package”  product  TMS  offers  is  not  what  CHT  needs. 
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3.  Echelon  Industries.  Inc. 

Initial  contact  with  this  systems  integration  company  and  conversation  with  its 
president  indicated  that  development  of  a  product  appropriate  for  CHT  would  not  be 
cost-effective.  Echelon  specializes  in  a  turnkey  data-collection  system  that  costs 
about  $10,000  per  vehicle  for  fleets  over  100.  Trying  to  adapt  this  system  to  a  small 
fleet  would  not  be  cost-effective,  and  Echelon  doesn’t  specialize  in  MDT’s. 

4.  Navigational  Data  Systems.  Inc. 

Initial  contact  with  this  company  indicated  that  although  it  produced  MDT’s,  its 
product  did  not  interface  with  Trapeze’s  Pass  or  Minipass  CAD  systems.  It  would  not 
be  cost-effective  for  NDS  to  develop  this  interface.  The  company  did  not  indicate 
interest  in  working  with  CHT  for  this  reason. 
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4.5  Summary  of  Findings 


Chapter  4  has  addressed  the  issue  of  choosing  an  MDT  vendor.  GMSI  and  Mentor  were 
the  two  companies  that  emerged  because  they  offered  a  product  appropriate  for  CHT’s 
needs.  Here,  the  findings  presented  in  Sections  4.1,  4.2,  and  4.3  will  be  summarized  in 
terms  of  positive  and  negative  aspects  of  both  companies.  The  summary  table  (Figure 
15)  can  be  found  on  the  following  page. 

The  table  shows  that  GMSI  has  a  bigger  company  with  local  representation.  Its  product 
transmits  data  and  processes  messages  more  quickly  than  Mentor’s,  but  this  benefit  is  not 
significant  for  a  system  as  small  as  CHT’s.  Mentor  outranks  GMSI  in  cost  and 
experience,  and  offers  a  product  recognized  by  other  transportation  companies  for  its  high 
quality  and  flexible  fimctionality. 

We  recommend  that  CHT  choose  Mentor  Engineering  over  GMSI,  Inc.  because  of  its 
cost.  Mentor’s  paratransit  experience,  and  client  feedback. 
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initial  cost:  $46,470  Total  initial  cost:  $34,034  Mentor 

added  annual  cost:  $2,902  Total  added  annual  cost:  $2,495 _ 


Chapter  5: 
Recommendations 


Based  upon  these  findings,  we  recommend: 

1)  CHT  should  consider  MDT’s  as  a  good  option  to  improve  current 
paratransit  operations  in  these  ways: 

•  reduced  dispatcher  workload,  allowing  more  time  for  better 
dispatching  decisions  and  caller  service 

•  faster,  clearer,  and  less  error-prone  driver/dispatcher  communication 

•  more  on-time  trips 

•  trip  time  and  mileage  reporting  capabilities 

Investigation  of  the  possibility  of  putting  MDT’s  on  CHT’s  paratransit  system  has 
shown  that  they  have  potential  to  improve  operations  in  many  ways.  CHT  should 
seriously  consider  adding  MDT’s  to  its  fleet,  especially  if  $67,000  is  a  reasonable 
amount  to  spend  and  if  it  has  committed  to  long-term  use  of  Minipass  or  some 
other  dispatching  software. 

2)  CHT  should  decide  whether  it  will  make  a  long-term  commitment  to  using 
Minipass.  If  so,  it  will  be  in  a  position  to  begin  the  process  of  installing 
MDT’s.  If  not,  CHT  will  need  to  do  further  research  to  commit  to  another 
dispatching  software  package  before  installing  an  MDT  system. 

Contracting  to  interface  MDT’s  with  scheduling  software  makes  up  about  half  of 
the  total  cost  to  install  MDT’s.  This  money  will  be  well  spent  only  if  this 
interface  is  usable  for  the  long  term. 

If  CHT  decides  to  implement  MDT’s,  we  also  recommend: 

1)  CHT  should  pursue  Mentor  Engineering  as  the  best  vendor  option  for  this 
system.  Mr.  Brent  Freer,  the  sales  representative  we  worked  with  during  the 
study,  is  the  point  of  contact.  CHT  should  arrange  for  a  visit  and 
presentation  from  the  company. 

GMSI  offers  a  high-quality  product,  but  any  gains  over  Mentor  from  its  higher 
speed  and  larger  memory  would  only  be  seen  in  large  systems.  Mentor  has  more 
paratransit  experience,  more  experience  working  with  Trapeze,  and  favorable 
response  from  its  clients  and  other  companies  in  the  field.  Combined  with  its 
significantly  lower  system  cost,  these  reasons  make  Mentor  a  better  choice  for 
CHT. 

2)  CHT  should  take  early  steps  to  gain  the  second  radio  frequency  needed  for 
the  MDT  system.  Mr.  Dyke  Hostettler,  State  Frequency  Coordinator  for 
North  Carolina,  is  the  point  of  contact.  It  should  also  contact  a  radio 
consultant,  possibly  Mr.  Larry  Sparks,  to  consider  the  possibility  of  using  his 
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services  to  ensure  an  adequate  radio  system. 

3)  CHT  should  begin  to  work  toward  a  contract  with  Trapeze  Software  Group 
for  the  MDT  -  Minipass  interface.  The  point  of  contact  is  Mr.  Dean 
Richardson.  The  contract  should  contain  a  commitment  from  Trapeze  to 
staying  until  the  interface  is  running  smoothly,  since  CHT  would  be  the  first 
Minipass-MDT  interface  site. 
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Appendix  A: 

Phone  and  Radio  Activity  Results 


Data  collection  for  the  dispatcher  busy  time  analysis  required  monitoring  rate  of  call 
arrivals  and  duration  of  calls  for  both  the  phone  and  the  radio.  Results  for  average  call 
length  and  duration  for  phone  and  radio  were  compiled  and  are  presented  here. 
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Appendix  B: 

CHT  Paratransit  Driver  Survey 


On  a  scale  from  1  to  5,  please  indicate  whether  or  not  you  agree  with  the 
following  statements: 


Strongly 

Disagree 

Neutral 

Agree 

Strongly 

Disagree 

Agree 

1. 

1  am  satisfied  with  the  way  driver- 
dispatcher  radio  communications 

1 

2 

3 

4 

5 

currently  work. 

4 

3 

3 

3 

2. 

1  usually  get  a  response  the  first  time 

1 

2 

3 

4 

5 

1  call  out  to  the  dispatcher. 

2 

5 

I 

4 

3. 

1  find  talking  over  the  radio  while 
driving  to  be  a  distraction. 

1 

2 

3 

4 

5 

1 

3 

5 

I 

2 

4. 

With  the  appropriate  training,  1  think  1 
would  be  comfortable  with  the  idea  of 

1 

2 

3 

4 

5 

using  an  MDT  in  my  vehicle. 

3 

3 

6 

5. 

1  think  MDT's  are  a  good  idea. 

1 

2 

3 

4 

5 

2 

3 

2 

5 

How  much  of  the  time  do  you  have  to  call  out  to  the  dispatcher  more  than 
once  before  getting  a  response?  (Circle  one) 


Never  Rarely  About  1/4  of  the  time  About  1/2  the  time 
4  3  3 


More  than  1/2  the  timt.' 
3 


How  often  do  you  have  repeat  yourself  or  ask  the  dispatcher  to  repeat 
him/herself  because  a  message  was  unclear?  (Circle  one) 


Never  Rarely 
3 


About  1/4  of  the  time  About  1/2  the  time 
3  4 


More  than  1/2  the  time 
3 


About  how  many  times  per  day  do  you  find  yourself  waiting  at  a  stop  to  find 
out  where  you  need  to  go  next?  (Circle  one) 

0  1-3  4-6  7-10  More  than  10 

15  5  1  1 


Do  vou  ever  leave  a  stop  without  knowing  your  next  destination?  Yes  No 

^  12  j 

If  yes,  about  how  many  times  per  day? _ 1-2 ,1-3 ,2-3 , 3 , 3-4 , 4 , 4 , 

4-6,20 


What  are  the  benefits  of  using  the  radio  to  communicate  with  the 
dispatcher? 

Knowing  where  to  go  and  who  to  pick  up. 

To  find  locations . 

Directions  may  be  needed. 

Patron  may  have  a  question . 

Roads  may  be  blocked. 

More  people  may  need  to  ride. 

Spur  of  the  moment  trips,  it  seems,  could  be  handled  more 
easily  by  an  efficient  radio  system. 

The  radio  is  of  no  benefit  to  me  because  most  of  the  time  I 
can't  get  the  dispatcher  to  answer.  Also,  a  lot  of  times 
the  drivers  are  talking  on  top  of  each  other. 

Emergencies !  (What  will  MDT's  provide  for  us?) 

A  voice  for  immediate  response  to  varying  (sometimes 
critical)  situations  that  happen  en  route  or  at  a  point  of 
pick  up. 

Responding  to  disabled  vehicles  and/or  accidents . 

Most  times  you  can  keep  traffic  flowing  smoothly .  I  feel 
that  MDT's  would  be  more  of  a  distraction,  (too  many 
buttons,  placement  in  van,  etc.)  More  cost-effective 
solution  would  be  separate  channels  for  fixed-route  and  EZ 
Rider. 

Portability  -  if  I  get  out  of  car  to  use  bathroom,  etc.,  I 
can  easily  carry  radio  with  me. 

Quick  response  -  if  I  need  assistance  or  dispatcher  needs  to 
make  last-moment  adjustments  to  schedule,  radio  seems 
quickest  and  easiest  means. 

Able  to  depart  van  and  carry  radio. 

Help  with  details  of  unfamiliar  pickups,  the  human  touch. 


What  are  the  drawbacks  of  using  the  radio  to  communicate  with  the 
dispatcher? 

Not  being  able  to  talk  to  the  dispatcher  when  I  need  to. 
May  get  a  call  while  on  turn  or  picking  up. 


A  lot  of  radio  traffic. 

Clear  {perhaps  this  person  means  unclear)  communications 
between  parties. 

Driving  and  talking! 

Radios  do  not  have  a  stable  place. 

Too  much  radio  traffic  because  we  share  frequency  with 
driver  I's  side.  With  good  radio  communication,  we  really 
run  efficiently. 

Mostly,  the  dispatcher  not  answering  the  radio. 

Background  interference,  always  hear  the  supervisors ,  fixed 
route  dispatchers  talking  while  EZ  dispatcher  is  trying  to 
give  trip,  and  telephone  ringing. 

It  all  sounds  very  unprofessional  on  the  airwaves.  I've 
received  numerous  complaints  about  all  the  laughing, 
yelling,  etc,  when  passengers  hear  this.  Use  of  universal 
"10"  codes  would  certainly  help.  Also,  train  dispatchers  in 
"airwave  etiquette",  i.e.,  they  fuss  at  drivers  on  the  air, 
talk  to  us  in  a  demeaning,  sarcastic  tone,  or  do  not  have  a 
voice  for  radio  communication  at  all  (very  muffled)  . 

Difficulty  getting  through,  understanding  one  another. 

Tarheel  Express  needs  to  be  on  another  channel,  (also  bus 
dispatcher) 

Can't  always  tell  when  another  driver  is  calling  in. 
Background  noise. 

What  is  your  initial  response  to  the  idea  of  using  an  MDT  in  your  vehicle? 

I  think  it  has  potential,  but  I  would  think  having  radio 
backup  would  be  advisable .  Then  again,  I  wonder  if  our 
radio  system  could  be  improved  at  a  lot  less  expense. 

I  like  the  idea,  mostly,  but  do  have  some  reservations  as  ■ 
stated  in  previous  questions . 

Would  like  to  see  it  in  operation  before  it's  a  permanent 
fixture  here. 

It's  worth  a  try! 

Very  skeptical !  I  know  nothing  about  MDT's  but  wonder  where 
it  would  be  mounted,  how  time-consuming  to  enter  data,  what 
happens  when  more  than  one  driver  enters  data  at  the  same 


time,  does  it  depend  upon  drop-offs  and  pick-ups  being  made 
in  a  certain  order? 

The  change  is  welcomed. 

O.K. 

May  be  more  effective  and  time  consuming  (Perhaps  this 
person  means  less  time  consuming)  . 

I  think  that  this  will  be  a  good  idea,  if  it  won't  take  too 
much  of  the  driver's  time. 

Bad  idea. 

Mild  interest . 

Please  include  any  other  comments  you  may  have  here: 

MDT's  may  keep  driver  stationary  -  wouldn't  be  able  to  step 
out  of  van  because  waiting  for  next  trip  on  computer  screen. 

If  in  danger,  someone  may  not  hear  you. 

I'd  have  to  see  what  an  MDT  looks  like  and  how  it  works  to 
really  give  an  opinion. 

EZ  Dispatcher  should  be  two  people  in  a  sound  proof  room 
during  peak  hours. 

Turn  car  shuttle  over  to  fixed  route  dispatchers . 

Weigh  cost  of  equipment  to  another  channel. 

I'm  not  a  raving  Luddite  but  oftentimes  greater  tecnnology 
leads  to  different  problems  rather  than  a  blanket  solution 
to  problems . 


Appendix  C: 

Multiple  Attempts  To  Reach 
Dispatcher  ~  A  CTMC  Model 


C.l  Problem  Overview 

In  this  model,  we  wanted  to  evaluate  the  percentage  of  the  time  that  a  driver  receives 
response  from  the  dispatcher  upon  his  first  attempt  to  relay  a  message.  In  other  words, 
what  is  the  probability  that  a  driver  attempting  to  relay  a  message  will  find  the  dispatcher 
to  be  free? 

In  order  to  answer  this  question,  we  modeled  the  activity  of  driver/dispatcher  interaction 
as  a  Continuous  Time  Markov  Chain  (CTMC).  In  particular,  this  CTMC  was  based  on  a 
finite-source  retrial  queueing  model,  in  which  we  make  the  following  definitions  and 
assumptions: 

•  The  state  is  defined  by  the  dispatcher’s  availability,  the  number  of  drivers  being 
served,  and  the  number  of  drivers  in  “orbit”.  An  orbiting  driver  is  one  who  made 
an  initial  attempt  to  receive  service,  but  found  the  dispatcher  busy,  and  is  now 
retrying  at  a  given  rate.  If  the  dispatcher  is  available  (i.e.,  she  is  not  occupied  by  the 
telephone  or  by  fixed-route  bus  radio  calls),  then  the  current  state  is  denoted  by  (#  in 
orbit,  #  being  served).  If  the  server  is  unavailable  while)  customers  are  in  orbit,  the 
current  state  is  denoted  by  Uj. 

•  Any  driver  who  does  not  receive  dispatcher  response  on  his  first  attempt  to  relay 
a  message  will  automatically  begin  to  orbit,  retrying  his  call  until  he  does  receive 
a  response. 

•  There  are  always  five  drivers  on  the  road.  In  actuality,  the  number  of  drivers 
fluctuates  a  little  bit  during  the  day,  but  the  daily  average  is  five  vehicles. 

•  When  the  dispatcher  is  on  the  telephone  or  using  the  radio  to  communicate  with 
fixed-route  vehicles,  she  will  not  respond  to  any  incoming  paratransit  calls. 

Observation  showed  that  sometimes  the  dispatcher  would  respond  to  a  radio  call 
while  on  the  phone,  but  this  did  not  occur  the  majority  of  the  time. 

•  Upon  entering  a  particular  state,  the  system  will  remain  in  that  state  for  a 
random,  exponentially  distributed  amount  of  time.  This  assumption  allows  for  the 
“memoryless”  property  needed  for  a  CTMC  model:  for  any  states  X  and  Y  in  the 
system’s  state  space,  the  probability  that  the  system  enters  state  Y  from  its  current 
state  X  is  dependent  only  upon  the  system’s  current  state,  and  is  independent  of  any 
of  the  system’s  previous  states.  In  our  model,  we  used  observed  dispatcher’s  booth 
activity  to  determine  values  for  the  rates  at  which  the  system  moves  between  states. 
We  assumed  that  these  observed  averages  were  parameters  of  exponential  random 
variables. 

A  rate  diagram  of  the  model  is  on  page  C-3.  The  rate  matrix  is  on  page  C-4.  These  two 
figures  are  followed  by  a  discussion  of  parameters  and  how  their  values  were  determined. 
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Figure  Cl  -  Driver-Dispatcher  Communication  CTMC 
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C.2  Data  Collection  and  Parameter  Estimates 


The  data  used  in  this  problem  was  the  same  data  used  for  the  dispatcher  busy  time 
analysis.  In  the  dispatcher’s  booth,  the  number  and  duration  of  both  incoming  phone  and 
radio  calls  was  recorded.  In  addition,  incoming  radio  calls  from  fixed-route  vehicles  were 
tracked.  Although  another  individual  in  the  dispatcher’s  booth  actually  answers  these 
calls,  they  are  important  because  they  tie  up  the  radio  channel,  forcing  the  dispatcher  to 
become  unavailable. 

Each  parameter  was  estimated  for  three  different  sets  of  data: 

1.  Activity  between  9:00  and  10:00  am 

2.  Activity  between  10:00  and  1 1 :00  am 

3.  Activity  over  the  whole  7:00  am  -  5:00  pm  observation  period. 

Since  the  dispatcher  busy  time  analysis  showed  highest  activity  level  during  the  9-10:00 
and  10-11 :00  hours,  we  decided  to  run  this  model  for  each  of  those  hours.  We  also 
wanted  to  see  results  for  the  whole  observed  day.  The  rest  of  this  section  will  define  each 
parameter  and  explain  how  it  was  computed. 

The  parameter  X  is  the  rate  at  which  any  one  vehicle  generates  first-attempt  calls.  It  was 
not  possible  to  observe  X,  but  the  rate  at  which  incoming  calls  reached  the  dispatcher,  X, 
was  observed.  The  following  equation  relates  X  and  X\ 

X  =  5X(p(0,0)+p(U0))  +  4X(p(0,l)  +  p(l,0)  +p(Ul))  +  3X(p(2,0)  +  p(l,l)  +  p(U2)) 

+  2X(p(3,0)  +  p(2,l)  +p(U3))  +  2p((4,0)  +p(3,l)  +  p(U5)) 

This  formula  comes  from  the  fact  that  incoming  calls  are  received  at  the  same  rate  at 
which  initial  call  attempts  are  generated.  Furthermore,  initial  call  attempts  are  generated 
at  a  rate  proportional  to  the  the  number  of  vehicles  which  are  not  being  served  or  in  orbit. 
The  formula  conditions  upon  the  state  of  the  system  to  determine  the  rate  at  which  initial 
call  attempts  are  produced. 

Since  the  steady-state  probabilities  are  unknown,  we  needed  to  determine  a  way  to 
approximate  X.  We  used  the  formula 


X  —  SXpjf-QQ  +  4Xpl}iisy, 


where  pfree  is  the  fraction  of  time  the  dispatcher  is  not  on  the  radio  and  phusy  1  ~Pfree- 
This  approximation  assumes  that  the  probability  that  any  vehicle  is  in  orbit  will  be  small. 
Our  results  are  consistent  with  this  assumption. 
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The  parameter  jj.  is  the  rate  at  which  vehicle  calls  are  serviced.  It  is  equal  to 
3600/(Average  Observed  Radio  Call  Length  (s)). 

The  parameter  is  the  rate  at  which  a  driver  whose  first  message  attempt  did  not  receive 
response  will  retry  to  contact  the  dispatcher.  This  value  was  not  actually  observed. 

Three  different  values  were  used  in  each  scenario;  they  corresponded  to  the  driver  waiting 
either  5, 10,  or  15  seconds  between  retrials.  These  values  are  appropriate  choices,  based 
on  time  spent  on  van  rides. 

The  pjirameter  9  is  the  rate  at  which  the  dispatcher  becomes  unavailable,  either  due  to  the 
arrival  of  a  telephone  call  or  fixed-route  vehicle  radio  call.  It  was  determined  by 
summing  the  average  number  of  incoming  phone  and  fixed-route  radio  calls. 

The  parameter  p  is  the  rate  at  which  the  dispatcher  goes  from  being  unavailable  to 
available.  It  is  equal  to 

3600/(Weighted  Average  of  Observed  Phone  Call  and  Fixed-Route  Radio  Call  Lengths  (s)) 
Figure  C3  gives  the  estimates  for  each  of  the  parameters: 


1 

00-10:00  am 

10:00-11:00  am 

,  7:00  am-S:00  pm 

. * 

(cails/bfO 

(calls/hr.) 

(calbs/hr,) 

:  1  ■ 

10.2 

9.64 

8.89 

\ 

260 

203 

262 

S  \ 

lAmeonio 

240/360/720 

240/360/720 

e 

26.7 

27.7 

26.7 

;  \ 

\  P 

106 

122 

131 

Figure  C3  -  Parameter  Estimates 


C.3  Solving  the  Problem 

Using  these  parameter  values,  we  were  able  to  find  the  steady-state  probabilities  that  the 
system  would  be  in  each  state.  This  problem  was  solved  for  nine  different  combinations 
of  values  (three  scenarios,  with  three  values  of  6  each).  It  was  solved  using  the  following 
equations; 

pQ  =  0; 

2:p  =  1, 


where  Q  is  the  CTMC’s  rate  matrix,  and  p  is  the  vector  of  steady-state  probabilities.  The 
solutions  to  these  equations  was  found  by  using  Matlab,  and  they  are  shown  in  Figure  C4. 
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Steady-State  Probabiiitie^ 


Figure  C4  -  Steady-State  Probabilities 


We  expressed  the  probability  that  the  driver  has  a  successful  first  message  attempt  with  this 
equation: 

P {Driver  Gets  Through  on  First  Try}  = 

(Rate  of  Message  Arrival  While  Server  is  Free)/(T otal  Arrival  Rate) 

In  terms  of  steady-state  probabilities,  this  can  be  written  as: 

PfDriver  Gets  Through  on  First  Try)  = 

[5p(0,0)  +  4p(l,0)  +  3p(2,0)  +  2p(3,0)  +  p(4,0)]  / 

[5(p(0.0)  +  p(O.I)  +p(U0))  +  4(p(1.0)  +p(],I)  +p(UI))  + 

3(p(2.0)  +  p(2,l)  +p(U2))  +  2(p(3,0)  +  p(3J)  +  p(U3)  )  +  p(4.0)  +p(4,l)  +  p(U4)] 

Figure  C5  shows  this  probability  for  each  of  the  nine  versions  of  the  problem: 


Problem  Version 

P(Successful  First  Attempt) 

P(Failed  First  Attemt) 

7am-5pm,  8  =  240 

0.708 

0.292 

7am-5pm,  5  =  360 

0.708 

0.292 

7am-5pm,  8  =  720 

0.707 

0.293 

9am-10am,  8  -  240 

0.668 

0.332 

9am-10am,  8  =  360 

0.668 

0.332 

9am-10am,  8  =  720 

0.667 

0.333 

10am-11am,  8  =  240 

0.651 

0.349 

lOam-1 1am,  8=360 

0.650 

0.350 

1 0am-1 1  am,  8  =720 

0.649 

0.351 

Figure  C5  -  Problem  Results 
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C.4  Summary  of  Results 


The  results  of  this  model  indicate  that  in  peak  hours,  there  is  less  than  a  70%  chance  that  the 
driver  will  reach  the  dispatcher  on  her  first  attempt  to  relay  a  message.  This  analysis  confirms 
the  driver  survey  results  that  multiple  attempts  to  reach  the  dispatcher  are  a  significant  issue.  It 
can  also  be  noted  that  the  value  chosen  for  d  doesn’t  significantly  affect  the  problem’s  results, 
and  that  even  the  average  daily  activity  observations  indicate  failed  message  attempts  almost 
30%  of  the  time. 
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Appendix  D: 
Contacts 


■•  •Name.,  h 

i  €MSI,Ifle. 

Greg  Davis 

Senior  Account  Representative 

{941)481-9215 

IRD-Teleride 

Dana  Aldercom 

Marketing  Coordinator 

(416)  408-9402 

Mentor  In^aeeriiig 

Brent  Freer 

Sales/Marketing 

(403)777-3764 

NC  State  Highway  Patrol 

Dyke  Hostettler 

NC  Frequency  Cooridinator 

(919)  662-4440 

Sparcom  Corporation 

Larry  Sparka 

Radio  Consultant 

(513)761-7377 

Transportation  Management 
Solutions,  Inc. 

Mark  Krueger 

Sales  Manager,  Eastern  Region 

(410)850-7890, 

x4116 

Trapezo  Software  Group 

Mr.  Dean  Richardson 

Regional  Sales  Representative 

(513)474-7106 
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Appendix  E: 

UHF  Frequency  Search  Results 


From:  SHP-iMU  To:  Kaily  Mirone 


Data:  4/3/97  Tima;  15:48:31 


Paga  1  of  1 


Kelly  Mirone:  Per  phone  call,  LU  frequency  search  from  best  to  worst  LU  radio  service...  DKH 

APCO  AFC,  Inc. 

Fraquancy  saarch  Rasults  Run  Data:  04/03/97 

Short  Form  Total  Records  Found:  15 


out 

TX  Freq. 

Latitude 

Longitude 

Callsign 

Agency  Hame 

ST 

Cl 

SVC 

Power 

ERP 

Elev 

AAT 

Ant  Ht 

97.73 

452.70000 

35-  2-58 

78-52-  9 

MPKH694 

FATETTEVILLZ,  CITT  OF 

HC 

FXOT 

PL 

35.0 

55.62 

452.72500 

35-25-57 

79-12-56 

WPJT842 

CAROLIHA  POWER 

ASD  LIGHT 

HC 

FXO 

IW 

5.0 

50.0 

149 

97 

S3 

42.02 

452.65000 

35-32-59 

79-10-21 

MPJTa42 

CAROL I HA  POWER 

AHO  LIGHT 

HC 

FXO 

IW 

5.0 

50.0 

93 

26 

24 

40.58 

452.42500 

35-46-30 

78-38-21 

KBDL233 

CAROLIHA  POWER 

fi  LIGHT 

HC 

FB2 

IW 

75.0 

427.0 

102 

93 

38.56 

452.82500 

35-47-49 

78-39-  9 

WFP500 

HORTK  CAROLIHA 

,  STATE  OF 

HC 

FXl 

PS 

45.0 

90.0 

101 

23 

35.93 

452.75000 

35-35-32 

79-  3-  a 

MHTKS88 

CAROLIHA  POWER 

AHD  LIGHT 

HC 

FXO 

IW 

S.Q 

30.0 

49 

30 

34.00 

452.32500 

35-47-56 

78-42-21 

MGH675 

HORTH  CAROLIHA 

,  STATE  OF 

HC 

FXO 

pp 

100.0 

221.0 

146 

61 

32.81 

452.47500 

35-47-13 

78-43-37 

WHWQ765 

W  E  MAHGUM  SBTERPRISES 

HC 

FB2 

LJ 

75,0 

158.0 

143 

122 

22.30 

452.62500 

35-56-30 

78-48-33 

Kai916 

CHF  TRAHSPORTATIOH  IHC 

HC 

PB2 

LJ 

75.0 

422.0 

131 

91 

19.49 

452.37500 

36-  2-14 

78-53-57 

KCZ487 

DURHAM  C0UHT7  HOSPITAL 

HC 

rx2 

PS 

75.0 

250.0 

122 

46 

14.84 

452.67500 

36-  2-21 

78-59-36 

WSSA660 

DURHAM,  CITT  OF 

HC 

FB2 

LU 

75.0 

220.0 

169 

46 

2.15 

452.35000 

35-54-41 

79-  4-41 

HPBBaeo 

CARRBORO,  TOWH 

OF 

HC 

FB2 

LV 

25.0 

7S.0 

143 

43 

1.19 

452.37500 

35-54-17 

79-  3-10 

KHXVP629 

0RAH6E,  COUHTT 

OF 

HC 

FX 

PS 

45  .0 

225.0 

149 

43 

1.19 

452.77500 

35-54-17 

79-  3-10 

KaiW629 

ORAHGB,  COUHTT 

OP 

HC 

FX 

PS 

45.0 

225.0 

149 

43 

0.00 

452.80000 

35-54-55 

79-  3-17 

KAG662 

CHAPEL  HILL,  TOWH  OF 

HC 

MO 

LU 

75.0 

Frequency (s)  Searched:  451.00000  Co  453.00000000  Service:  LU  Sorted  by:  Dist  From 

Distance  Expressed  as  Km  from  Coordinates  :  35-54-55  79-  3-17  State (s): 


RADIO  STATION  LICENSE  (reference  only) 

! 

Licensee  Name:  CHAPEL  HILL,  TOWN  OF 

Radio  Service:  LU  Issue  Date:  08/08/96 

Callsign:  KAfi662  Expire  Date:  09/27/01 

Freq .  Advisory  # : 

Mobiles:  Vehicular:  40  Portable:  5  Aircraft:  Pagers: 

TRANSPORTATION  DEPT 
CHAPEL  HILL,  TOWN  OF 
306  N  COLUMBIA  STREET 
CHAPEL  HILL,  NC  27514 


TX  Freq  Class 

(MHz) 

Hum 

Emiss 

Power 

ERP 

Elev 

Ht  to 
Tip 

Lati tude 

Longitude 

452.80000  MO 

73 

20K0F3E 

75.0 

0.0 

0 

0 

35-54-55 

79-  3-17 

457.80000  MO 

73 

20K0F3E 

75.0 

0.0 

0 

0 

35-54-55 

79-  3-17 

452.80000  FB 

1 

20K0F3E 

75.0 

0.0 

0 

43 

35-54-55 

79-  3-17 

Aop  :  136  EAST  ROSEMARY  ST 

CHAPEL  HILL  ,  NC  ORANGE 

Control  Points : 


Control  Point  Phone:  919-968-2755 
Special  Conditions: 
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Appendix  F: 
Minipass/A  VL  Letter 


PPR  07  ’97  13:03  FR  TRRPE2E  SOFTURRE 


602  627  8411  TO  19199682840 


P.02/02 


TM 

Trapeze  Software  Group,  Inc. 


15880  N.  Greenway  Hayden  Loop,  Suite  200,  Building  A,  Seottedale,  Arizona,  U.S.A.  85260 

Telephone  (602)  827-8400,  Fa*  (802)  827-8411 


STATEMENT  OF  ACKNOWLEDGEMENT 

Date:  April  4, 1997 
Project:  Chapel  Hill 
Re:  MDT  Inter&ce 


Attention:  KeUy  Mirone 


This  statement  of  ajcknowledgement  confirms  that  the  MDT  Interface  is  configurable  with  Trapeze  MINIPASS; 
however,  MINIPASS  will  not  support  AVL.  There  is  no  map  capability  or  functionality  for  latitude  or  longitude 
coordinates. 

Please  forward  any  questions  or  comments  you  might  have  to  my  attention. 


Regards, 


=K*  TOTAL  PfiGE.02 


Appendix  G: 

GMSI MDT  Functionality 


Mdt  4100  Series  -  Status  II 
Mobile  Data  Terminal 


Graphic  Display 


Downloaded 
Forms  Capability 


Flexible  GPS 
Reporting 


Multiple 

Communications 

Networks 


The  MDT  4100  Series  -  Status  Mobile  Data  Terminal  (MDT)  is  a  rugged  in-vehicle  terminal  providing  high 
speed  data  communications  between  dispatch  center  and  fleet.  Software  is  tailored  to  meet  industry 
specific  needs. 


Software  Applications: 

•  Taxi 

•  Fixed  Route  Transit 

•  Paratransit 

Communications  Networks 
Applications: 

•  Trunked  radio  systems 

•  Conventional  full  duplex  channels 

•  Simplex  channels 

•  Public  data  networks 


Operation: 

•  Easy  to  learn  and  use 

•  Menu  driven 

•  Large  readable  character  display 

•  LED  Backlit  display  and  keypad 

•  Forms  and  status  messages  support 

•  Adjustable  GPS  reporting 

Peripheral  Support: 

•  Integrated  odometer 

•  Emergency  alarm 

•  Contactless  smart  card  reader 

•  Magnetic  card  swipes 


Setting  The  Standard  In  Computerized  Mobile 
Data  Communications  Systems! 

All  brand  names  are  trademarks  or  registered  trademarks  of  their  respective  companies. 
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Specifications  —  Alpha/Status  II  &  III 


Offices 


Physical 

Item 

Width 

Height 

Depth 

;  GMSI,  Inc. 

:  275  Michael  Cowpland  Dr. 

Size  (in/mm) 

Integrated  Display/Keypad  - 

1  Kanata,  Ontario 

a/Status  II 

8/200 

4.25/100 

7/180 

!  Canada  K2M  2G2 

Status  ill  Keypad 

2.9/74 

3.88/98 

1/25 

:  Tel:  (613)  599-5161 

Status  III  Display 

8.25/210 

2.5/65 

2/50 

Fax:(613)599-6425 

MCU 

7/180 

1.5/40 

5.25/133 

Character 

GMSI,  Inc. 

Display  Size 

Single  Height  -  .15  in  /  4  mm 

Double  Height  -  .3  in  /  8  mm 

10999  Metcalf 

Overland  Park,  Kansas 

Power 

13.8  Vdc  nominal;  full  operation  over  10  Vdc  to  16  Vdc 

USA  66210 

Auxiliary  Output 

13.6  Vdc  at  500Ma 

Tel:  (913)  451-3003 

30  Minute  power  off  run  timer 

Fax:  (913)  338-0997 

Current 

Consumption 

mA 

MCU  and  Display/keypad  500 

GPS  350 

CPU 

Motorola  68331 ,  32  microcontroller  mnning  at  1 6  Mhz 

Memory 

256  kbytes  of  reprogrammable  memory  (Flash  ROM),  expandable  to 
512  kbytes  128  kbytes  of  RAM,  expandable  to  512  kbytes 

Programming 

The  MCU  application  software  and  lists  of  forms  and  status  messages 
can  be  upgraded  through  the  programming  port 

Environmental 

Temperature 

Operating:  -22°  to  +140°  Fahrenheit  (-30°  to  +65°  Celsius) 

Storage:  -50°  to +160°  Fahrenheit  (-45°  to +70°  Celsius) 

Mobile 

Environmental 

Testing 

SAEJ1455 

Electromagnetic 

Compatibility 

CE  Marking  (Europe) 

GMSI,  Inc. 

2119  St.  Mary's  Street 
Raleigh,  North  Carolina 
USA  27608 
Tel:  (919)  420-7734 
Fax:  (919)  420-7736 


GMSI,  Inc. 

33  Saddle  Rock  Road 

West  Greenwich,  Rhode  Island 

USA  0281 7 

Tel:  (401)  397-8086 

Fax:  (401)  397-8514 


GMSI,  Inc. 

3200  North  Lake  Shore  Dr. 

Suite  1501 

Chicago,  Illinois 

USA  60657 

Tel:  (312)  929-3143 

Fax:  (312)  929-3144 


Network  Operation  Requirements 


4115a 

4113  Status  II  GSM  (SMS).  Geonet,  MPT  1327  (Key),  MPT  1327  (Mapp  27) 
4125a 

4123  Status  II  Conventional  Channel,  Simplex  channel 


4135a 

4133  Status  11  E.F.  Johnson  trunking,  Motorola  trunking,  ED  AC’s  trunking 


4122a 

Status  111  Conventional  Channel 


GMSI,  Inc. 

18  The  Crescent,  Grants  Hill 
Ilford,  Essex 
England 
IG2  6JF 

Tel:  (0)  181-554-0785 
Fax:  (0)  181-518-5987 


GMSI,  Inc. 

do  National  Band  Three 
Wren  House 

Hedgerows  Business  Park 
Colchester  Park 
Chelmsford,  Essex 
UK,  CM2  5PF 
Tel:  (0)  171-396-3380 
Fax:  (0)  171-396-3377 


All  specifications  are  subject  to  change  without  notice.  -  4/96 
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ABC  Transit 


Section  7  -  Mobile  Data  Terminal  Requirements 

7.1  Introduction 

]h  this  section  ASC  has  listed  the  mininnim  MDT  ftmctionality  that  will  be  required  of  the 

successhil  vendor’s  MDCS. 

7.2  MDT  Functionality 

1 .  At  some  future  time  ABC  may  desire  to  expand  its  MDT’s  functionality  beyond  it  current 
lequiranents,  therefore  the  successful  vendor’s  MDT  will  have  the  c^ability  to  int^rate  and 
control  devices  such  as  card  readers,  GPS  receivers,  odometer  readers,  printers,  vdiide  saisors 
and  mobile  radios. 

2.  In  order  thitf  ABC  may  int^rate  and  control  such  devices  as:  card  readers,  GPS  receivers, 
odome<~er  readers,  printers,  vdiide  sensors  and  mobile  radios,  the  successful  vendor’s  MDT 
will  contain  a  minimum  of  2  Mbytes  of  prc^rammable  memory  (Flash  ROM)  and  be 
eiqiandable  to  4  Mbytes. 

3.  The  flash  memory  Awill  be  programmed  by  connecting  a  PC,  running  a  configuration  program, 

to  one  of  the  MDT  serial  ports. 

4.  hi  order  thiit  ABC  may  process  the  information  collected  and  stored  firom  such  devices  as:  card 
readers,  GPS  receivers,  odometer  readers,  printers,  vdiicle  sensors  and  mobile  radios,  tiie 
successfiil  vendor’s  MDT  will  contain  a  32  bit  processor. 

5 .  Should  the  MDCS  experience  a  communications  fiiilure,  after  ABC  has  download  the  driver’s 
manifest  the  MDT  will  be  capable  of  functioning  indqieidentiy  of  the  MDCS  base.  This 
functionality  will  allow  the  driver  to  continue  worldng  from  the  manifest,  thareby  collecting 
and  storing  normal  rider  and  trip  data  in  the  MDT.  Once  the  data  link  between  the  MDCS 
base  and  MDT  is  restored,  the  MDT  will  prompt  the  driver  to  said  the  stored  rider  and  trip 
data.  In  order  for  the  MDT  to  be  able  to  store  an  entire  day’s  manifest  and  also  be  able  to 
collect  and  store  tiiat  day’s  rider  and  trip  data  it  will  contain  a  minimum  of  128  Kbytes  of 
RAM. 

6.  The  MDT’s  transmission  speed  will  be  3600  bits  per  second  or  faster. 

8.  MDT  forms  and  prompts  will  be  programmed  firom  the  MDCS  computer  via  the  radio  link. 

9.  The  MDT  power  will  be  controlled  by  the  vdiicle’s  run  switch. 

10.  The  MDT  will  be  activated  when  the  vdiicle’s  run  switdi  is  turned  on. 

/ 

11.  The  MDT  will  be  deactivated  when  the  vdiicle’s  run  switch  is  turned  off. 
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12.  ABC  will  have  the  option  of  having  the  vendor  configure  file  MDT  so  that  it  will  remain  on 
and  operational  for  a  period  of  time,  to  be  determined  bv^C  after  the  vdiide’s  run  switch 
has  been  turned  off.  This  feature  will  allow  ABC  drivers  to  turn  off  the  vdiide’s  engine  and 
a^s**?*"  riders  fiiat  are  away  from  the  vdude  vdiile  other  riders  remain  on  the  vdiide,  without 
losing  trip  information  and  collected  data  stored  in  the  MDT. 

13 .  The  MDT  will  provide  adequate  filtering  and  protection  to  prevent  intoference  from  florescent 
lights  and  the  vdhide’s  alternator. 

14.  The  driver  will  be  alerted  of  incoming  messages  by  a  buzzer.  The  buzzer  will  be  located  in  the 
MDT  and  will  be  loud  enou^  to  be  easily  heard  by  the  driver. 

15.  Using  the  keypad,  the  driver  will  acknowled^  ncrification  of  incoming  messages.  Once  the 
driver  has  adoiowledged  an  incoming  message  it  will  be  shown  on  the  MDT  display . 

16.  The  driver  will  have  twenty  (20)  seconds  to  acknowledge  incoming  messages.  After  twenty 

(20)  with  no  acknowledgment,  fire  MDCS  conq)uter  will  transmit  the  message  again. 

After  a  second  and  third  attonpt  without  acknowledgment,  the  MDCS  conqjuter  will  iirform 
the  communications  siq)ervisor  of  the  driver’s  &ilure  to  acknowledge  the  message.  The  MDCS 
conqiuter  will  store  messages  fiiat  have  not  been  acknowledged. 

17.  ABC  will  have  the  qption  of  configuring  the  MDCS  computer  so  that  it  can  specify  the  length 
of  time  the  driver  has  to  respond  to  incoming  messages  and  the  number  of  times  the  MDCS 
computer  will  transmit  a  message  that  has  not  been  adoiowledged. 

18.  Once  the  MDCS  computer  has  re-established  communications  with  the  MDT,  it  will  pronqit 
the  communications  svqiervisor  to  transmit  stored  messages. 

19.  If  the  MDT  foils  to  receive  an  acknowledgment  from  file  MDCS  conqiuter  after  attempting  to 

send  a  it  will  pronqit  the  driver  to  attempt  to  send  the  message  again.  After  a  second 

and  tihird  driver  prompt  and  transmission  attenqit,  ivithout  acknowledgment,  the  MDT  will 

the  vehide  is  a  poor  radio  coverage  area  and  will  prompt  the  driver  to  move  the 

vdhicle. 

20 .  At  any  time  after  the  driver  has  legged  on  to  the  systan  and  received  a  trip  manifest,  the 
MDCS  will  update  that  manifest  by  inserting  additional  trips  sent  to  it  by  the  dispatdi  system 
coirqiuter.  The  driver  will  be  alerted  of  a  trip  insertion  message  by  the  MDT  buzzer.  The 
driver  will  acknowledge  receipt  of  the  trip  insertion  by  pressing  the  ACKN  and  SEND  k^  on 
the  MDT  keypad.  The  MDT  will  automatically  insert  additional  trips  in  the  order  of  their 
sdieduled  pick  up  or  drop  off  times. 

21 .  At  any  tima  after  the  driver  has  logged  on  to  the  system  and  received  a  trip  manifest,  foe 
MDCS  will  vpdate  that  manifest  by  canceling  trips.  The  driver  will  be  alerted  of  a  trip 
cancdlation  message  by  foe  MDT  buzzer.  The  driver  will  acknowledge  receipt  of  foe  trip 
cancdlation  by  pressing  foe  ACKN  and  SEND  keys  on  foe  MDT  keypad.  Die  MDCS  will 
automatically  delete  foe  trip  from  foe  manifest  and  display  “TRIP  CANCELED”  on  foe 
driver’s  display,  vfoere  foe  ddeted  rider’s  address  was  originally  shown. 
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7.2.1  MDT  Display 

1 .  The  MDT  will  have  a  liquid  crystal  display  screen. 

2.  The  display  will  be  back  lit  for  ni^  viewing. 

3 .  The  display  screen  will  be  capable  of  displaying  a  full  ASCII  character  s&.  with  blinking,  bold, 
and  underlined  diaracters. 

4.  The  Hi  splay  screen  wiU  be  capable  of  displaying  both  ^iper  and  lower  case  diaracters. 

5 .  The  display  will  show  messages  and  trip  assignments  sent  to  the  drivCT  by  the  MDCS 
cmnputer. 

6.  The  display  will  have  a  minimum  of  six  (6)  lines,  each  containmg  a  minimum  of  forty  (40) 
characters. 

7.2.2  MDT  Keypad 

1 .  The  MDT  keypad  will  allow  drivers  to  communicate  trip  status  iqidates  and  form  messages  to 
the  dispatch  center. 

2.  Each  keypad  button  will  be  back  lit  for  night  viewing. 

3.  The  MDT  keypad  will  feature  soft  and  hard  coded  function  keys. 

4.  The  hard  coded  keys  will  be  fixed  function  keys  programmed  and  labeled  by  Ihe  vendor  and  in 
conjunction  with  ABC. 

5 .  The  soft  coded  fimction  keys  wiU  be  menu  driven  and  will  diange  function  depending  on  the 
menu  context. 

6.  Initially  the  soft  coded  function  ke3^  will  be  programmed  by  the  vendor  and  in  conjunction 
with  ABC. 

7.  The  soft  coded  function  keys  will  allow  ABC  to  create  or  change  the  MDT’s  soft  function  keys 
at  its  discretion. 

8.  At  a  minimum,  the  MDT  keypad  will  provide  the  following  driver  functions: 

a)  adjustment  of  the  display  contrast, 

b)  adjustment  of  the  bri^Ttness  of  the  display  back  li^ 

c)  cancellation  of  an  incorrect  keypad  sequence  before  saiding  information  to  the 
communications  computer, 

d)  advancement  of  information  displayed  on  the  MDT  display, 

e)  renewing  the  driver’s  manifest, 

f)  displaying  driver  messages, 

g)  displaying  the  manifest  screen, 

h)  displaying  an  e}q)anded  manifest  screen. 
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i)  displaying  a  form  screen, 

j)  reporting  the  vdiicle’s  arrival  at  a  scheduled  stop, 

k)  rq)orting  a  sdieduled  rider  has  boarded  the  vdiide, 

l)  rq)orting  a  sdieduled  rider  has  exited  the  vdiide, 

m)  rqiorting  the  vehicle’s  departure  from  a  sdieduled  stq), 

n)  rqiorting  that  a  rider  is  not  at  the  pidoqj  point  (no  show), 

o)  rqiorting  that  a  rider  has  cancded  a  trip  at  the  pidaqj  point  (door  cancdlation), 

p)  rqiorting  that  a  rider  has  not  come  out  to  the  vehicle  and  the  driver  wishes  to  give  the 
siqiervisor  the  option  of  calling  the  rider  (call  out), 

q)  requesting  permission  to  speak  to  the  siq)ervisor  on  a  voice  channel, 

r)  requesting  priority  permission  to  speak  to  the  supervisor  on  a  voice  channel, 

s)  signaling  the  siqjervisor  of  an  anergency, 

t)  acknowledgment  of  receipt  of  messages  from  the  MDCS  computer, 

u)  transmission  of  canned  coded  messages, 

v)  transmission  of  forms  with  numeric  information,  and 

w)  compl^on  of  an  MDT  entry  sequence  that  will  said  messages  to  the  MDCS 
conqiuter. 
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Section  8  -  Driver  Interface  Requirements 

8.1  introduction 

Li  this  section  ASC  has  listed  the  minimum  driver  interface  functionality  that  will  be  required  of 
the  successful  vendor’s  MDCS. 

8.2  General  Requirements 

1 .  When  the  MDT  is  activated  it  will  automatically  conduct  a  sdtf  test  to  determine  if  it  is 
functioning  properly. 

2.  Once  the  MDT  has  passed  its  self  test  it  will  automatically  display  a  driver  1(^  on  form  screen 
requesting  the  driver’s  identification  number  and  the  vdiide’s  odometer  reading. 

3 .  Drivers  are  to  log  on  to  the  MDCS  by  entering  thar  identification  number  and  the  vdiide’s 

reading  into  the  MDT  and  then  transmitting  the  information  to  the  MDCS  computer. 

4.  A  successfiil  log  on  will  automatically  indicate  to  the  MDCS  that  the  driver  is  avadabie  to 
receive  and  transmit  messages. 

5 .  The  driver  will  be  alerted  of  incoming  messages  by  a  buzzer  located  in  the  MDT . 

6.  Using  the  keypad,  the  driver  will  acknowledge  incoming  messages. 

7.  Once  the  driver  has  acknowledged  an  incoming  message  it  will  be  shown  on  the  MDT  display. 

8.  ABC  will  have  tire  option  of  downloading  and  storing  iqj  to  one  hundred  (100)  rider/trip  stops 
in  the  MDT. 

9 .  The  driver  will  be  able  to  scroll  throu^  the  manifest. 

10.  All  driver  screens  will  display  the  current  system  time. 

1 1 .  The  system  time  will  be  dqiicted  by  a  twenty-four  (24)  hour  clock. 

12  The  system  time  will  be  set  by  the  MDCS  siqjervisor. 
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8.3  Driver  Screens 

The  MDT  will  provide  drivers  with  a  Manifest  Screen,  Expanded  Manifest  Screen  and  Form 

Screens. 

8.3.1  Manifest  Screen 

1 .  The  Manifest  Screen  will  provide  drivers  with  an  overview  of  their  manifest. 

2.  It  will  display  a  minimum  of  six  (6)  lines  of  40  characters  each. 

3 .  Additional  trip  message  lines  vnll  be  available  by  scrolling. 

4.  It  will  display  a  single  line  entry  for  eadi  trip/stop . 

5.  All  trips  will  be  shown  on  the  display  in  ascending  order  of  scheduled  stop  times. 

6.  Thecurrenttrip  will  be  located  at  the  top  of  the  manifest. 

7.  When  the  driver  con:q)l^es  the  current  trip,  the  MDCS  will  automatically  ddete  it  from  the 
manifest. 

8.  The  Manifest  Screen  will  display  multiple  rider  pick  ups  and  drop  offs  from  the  same  address. 

9.  At  any  time  after  the  driver  has  logged  on  to  the  system  and  received  a  manifest,  the  MDT  will 

iqjdate  the  manifest  by  inserting  additional  trips  sent  to  it  by  the  dispatch  S3^em.  The  MDT 
will  insert  jobs  in  the  order  of  their  sdieduled  pick  or  drop  off  times. 

10.  At  any  time  after  the  driver  has  logged  on  to  the  system  and  recaved  a  manifest,  the  MDT  will 
update  the  manifest  by  deleting  trips  that  have  been  canceled. 

1 1 .  The  driver  vtill  be  able  to  access  the  Form  Screens  from  the  Manifest  Screen  by  a  sii^e  key 
stroke,  using  an  MDT  keypad  key. 

12.  The  driver  will  be  able  to  access  the  Expanded  Manifest  Screen  from  the  Manifest  Screen  by  a 
single  key  stroke,  using  an  MDT  keypad  key. 

13 .  The  following  is  an  example  of  ABC’s  proposed  Manifest  Screen. 


7:00 

1010 

Pine  St.,  Seattle 

- 

7:30 

2109 

Steele  St.,  Seattle 

+ 

7:36 

5155 

James  St.,  Seattle 

+ 

7:45 

2300 

Reedy  Creek  Rd. ,  Seattle 

+ 

7:52 

2119 

ST.  Mary's  St.,  Seattle 

- 

8:00 

2454 

Pear  Orchard  Ln.,  Seattle 

a)  A  “+”  to  indicate  a  pick-vqj,  or  a  to  indicate  a  drop  off  will  be  the  first  diaracter  on 
each  line. 
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b)  After  the  “+”  or  sign,  the  screen  will  show  the  scheduled  stop  time.  If  the  driver  has  a 
scheduled  stop  time  window,  such  as  6:30  a.m.  to  7:00  a.m.,  the  screen  will  display  the 
latest  time  (7:00  a.m.)  that  the  driver  can  arrive  at  the  stop. 

c)  After  the  stop  time  the  line  will  show  the  stop  address. 

8.2.2  Expanded  Manifest  Screen 

1 .  The  Branded  Manifest  Screen  will  provide  the  driver  with  detailed  information  about  each 
stop. 

2.  The  E^qianded  Manifest  Screen  will  display  a  minimum  of  six  (6)  lines  of  40  characters  each. 

3.  Additional  lines  of  trip  information  will  be  available  by  scrolling. 

4.  The  driver  will  be  able  access  the  Manifest  Screen  from  the  Expanded  Manifest  Screen  by  a 
single  key  stroke,  using  an  MDT  keypad  k^. 

5 .  The  driver  will  be  able  to  access  the  Form  Screen  from  the  Expanded  Manifest  Screen  by  a 
sir^e  key  stroke,  using  the  an  MDT  keypad  key. 

6.  The  following  is  an  example  of  ABC's  proposed  Expanded  Manifest  Screen. 


+  7:00  1010  James  St.,  Seattle 
Mary  Logan  Fare  $3.00  209618844 

01 -Rider  01 -Attend  00 -Comp  Trip  #  011850 
Go  to  back  entrance.  Attendant  must 
assist  in  loading  rider.  Attendant 
fare  $3.00 


a)  The  first  line  of  the  Expanded  Manifest  Screen  will  display  a  “+”  to  indicate  a  pick  i:?)  or  a 

to  jnHirate  a  drop  off,  the  sdieduled  stop  time  and  the  stop’s  street  address. 

b)  The  second  line  will  display  the  rider’s  name,  fare  amount  and.<45C  customer  number. 

c)  The  third  line  will  display  the  number  of  riders,  attendants  and  companions  to  be  picked  iq) 
or  dropped  off,  and  the  dispatch  system  generated  unique  trip  number. 

d)  The  forth,  fifth  and  sixth  lines  will  display  additional  mformation  about  the  rider  or  stop, 
such  as  map-page  and  location  references,  special  instructions  or  commaits. 


8.2.3  Form  Screens 

1 .  Form  Screais  will  display  a  list  of  information  requests  to  be  filled  in  by  the  driver  and 
transmitted  to  the  MDCS  computer. 

2.  The  driver  will  be  able  to  access  the  Form  Screens  from  either  the  Manifest  Screen  or 
Expanded  Manifest  Screai  by  using  an  MDT  keypad  key. 
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3 .  After  the  driver  has  used  the  MDT  to  record  a  rider  ’  s  boarding,  ABC  will  have  die  option  of 
automatically  displaying  Form  Screens  to  be  filled  in  by  the  driver  and  transmitted  to  the 
MDCS  computer,  brfore  the  driver  can  return  to  any  other  screen. 

4.  If  a  Form  Screen  requires  the  vdiide’s  odometer  reading,  the  MDT  will  automatically  read  and 
fill  in  odometer  reading. 

5.  If  the  rider  and  trip  numbers,  number  of  riders,  attendants  and  companions,  and  fere  amounts 
and  types  were  in  the  original  trip  message  transmitted  to  the  MDT,  the  MDT  will 
automatically  place  that  information  in  the  appropriate  Form  Screai  fidds.  The  driver  will  be 
able  to  change  information  entered  by  the  MDT. 

6.  The  following  are  examples  c£ ABC’s  proposed  driver  Form  Screens. 


Odometer  [0012932] 
Rider  #  [825184683] 
Trip#  [01420] 

#  Riders  [01] 

Fare  [$3.00] 

Rider  Fare  Type  [01] 


a)  Line  one  (1)  will  request  the  vdiide’s  odometer  reading. 

b)  Line  two  (2)  will  request  the  rider’s  identification  number. 

c)  T.inft  three  (3)  will  request  the  dispatch  system  generated  trip  number. 

d)  Line  four  (4)  will  request  the  number  of  riders. 

e)  Line  five  (5)  will  request  the  fere  amount  collected  from  the  rider. 

f)  T,inft  six  (6)  will  request  the  type  of  fare  media  used  by  the  rider,  i.e.  cash,  token,  pass, 
transfer,  etc. 
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Section  9  -  Data  Collection  &  Service  Monitoring 

Requirements 


9.1  Introduction 

In  this  section  yjgC  has  listed  the  data  collection  and  service  monitoring  features  that  will  be 
required  of  the  successM  vendor’s  MDCS. 

9.2  Real-Time  Messaging 

1 .  The  successful  vendor’s  MDCS  will  said,  receive,  and  store  all  driver  messages  in  real-time. 

2.  The  time  and  date  at  which  messages  are  transmitted  and  recaved  will  be  recorded. 

3 .  The  identity  of  the  individual  transmitting  a  message  and  that  of  the  individual  acknowledging 
receipt  of  the  message  will  be  recorded. 

4.  Once  the  MDCS  computer  has  transmitted  a  driver  message  and  recaved  an  acknowledgment 
of  receipt  of  the  message,  the  message  will  be  stored  on  the  dispatch  system  conqiuter. 

5.  Once  the  MDCS  con^uter  has  acknowledged  recapt  of  a  driver  message,  the  message  will  be 
stored  on  die  dispatch  systan  computa. 

9.3  Coded  Driver  Messages 

It  is  ABC’s  intait  that  drivers  will  use  the  MDT  to  transmit  coded  or  canned  messages  to  the 
MDCS  computer.  It  is  also  ABC’s  intent  that  sudi  activity  will  cause  the  MDT  to  automatically 
collect  and  transmit  the  following  information: 

1.  message  content, 

2.  driva  idaitification  numba, 

3 .  vdiicle  identification  numba, 

4.  timfi  and  date  of  transmission, 

5 .  vehicle  odometa  reading,  and 

6.  vehicle  longitude  and  latitude. 
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9.4  Log  On 

It  is  ABC’s  intflnt  that  drivers  will  use  the  MDT  to  log  on  to  the  MDCS .  It  is  also  ABC’s  intent 
that  the  Ic®  on  activity  will  cause  the  MDT  to  automatically  coUect  and  transmit  the  following 
infonnation  to  the  MDCS  computer; 

1.  1<^  on  activity, 

2.  driver  identification  number, 

3 .  time  and  date  of  transmission, 

4.  vehicle  identification  number, 

5.  odometer  reading,  and 

6.  vdiide  longitude  and  latitude. 

9.5  Log  Off 

It  is  ABC’s  intent-  that  drivers  will  use  the  MDT  to  log  off  of  the  MDCS.  It  is  ABC’s  intent 

that  this  1<^  off  activity  will  cause  the  MDT  to  collect  and  transmit  the  following  infonnation  to  the 
MDCS  computer: 

1.  log  off  activity, 

2.  driver  identification  number, 

3 .  time  and  date  of  transmission, 

4.  vdiide  identification  number 

5.  odometer  reading 

6.  vdiide  longitude  and  latitude 

9.6  Pick  Up  Site  Arrival 

It  is  ABC’s  intent  that  drivers  will  use  the  MDT  to  indicate  that  the  vdiide  has  arrived  at  a 
scheduled  pick  igi  site.  It  is  also  ABC’s  intent  that  this  MDT  activity  will  collect  and  transmit  the 
following  information  to  the  MDCS  computer 

1.  pickup  site  arrival, 

2.  rider  identification  number, 

3 .  dispatch  system  gaierated  trip  number, 

4.  vehicle  identification  number, 

5.  time  and  date  of  transmission, 

6.  vehicle  odometer  reading,  and 

7 .  vehicle  longitude  and  latitude. 
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9.7  Pick  Up  Site  Departure 

It  is  ABC's  intpnf  that  drivers  will  use  the  MDT  to  indicate  that  the  vdiide  is  d^aidng  a 
scheduled  pidc  up  she.  It  is  also  ABC's  intent  that  this  MDT  activity  will  collect  and  transmh  the 
following  information  to  the  MDCS  computer: 

1 .  pidc  iqj  she  departure, 

2.  rider  identification  number, 

3 .  dispatch  system  generated  trip  number, 

4.  vdiide  identification  number, 

5 .  time  and  date  of  transmission, 

6.  vehide  odomrter  reading,  and 

7.  vehicle  longitude  and  latitude. 

9.8  Drop  Off  Site  Arrival 

It  is  ABC's  intent  that  drivers  will  use  the  MDT  to  indicate  that  the  vehicle  has  amvedat  a 
scheduled  drop  aS  site.  It  is  also  ABC's  intent  that  this  MDT  activity  will  collect  and  transmh  the 
following  information  to  the  MDCS  conq)uter: 

1 .  drop  off  she  arrival, 

2.  rider  idendficarion  number, 

3 .  dispatdi  system  generated  trip  number, 

4.  vehide  identification  number, 

5 .  time  and  date  of  transmission, 

6.  vdiide  odom^r  reading,  and 

7.  vdiide  longitude  and  latitude. 

9.9  Drop  Off  Site  Departure 

It  is  ABC's  intent  that  drivers  will  use  the  MDT  to  indicate  that  the  vdiide  is  dgiarting  a 
scheduled  drop  off  she.  It  is  also  ABC's  intait  that  this  MDT  activity  will  collect  and  transmit  the 
following  information  to  the  MDCS  computer: 

1.  drop  off  she  dgiarture, 

2.  rider  identification  number, 

3 .  dispatch  system  generated  trip  number, 

4.  vdiide  identification  number, 

5 .  time  and  date  of  transmission, 

6.  vdiide  odometer  reading,  and 

7.  vehide  longitude  and  latitude. 
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9.10  Rider  Boarding 

^  is  intent  that  drivers  will  use  the  MDT  to  indicate  that  sdieduled  rider  has  boarded  the 

vehicle.  It  is  also  ABC’s  intent  that  this  MDT  activity  wiU  collect  and  transmit  the  following 
information  to  the  MDCS  computer: 

1.  boarding  activity, 

2.  rider  identification  number, 

3 .  dispatch  system  generated  trip  number, 

4.  vdiide  identification  number, 

5.  time  and  date  of  transmission, 

6.  vehide  odometer  reading,  and 

7.  vehide  longitude  and  latitude. 

9.11  Rider  Alighting 

It  is  JiC\  intent  that  drivers  will  use  the  MDT  to  indicate  that  scheduled  rider  has  ali^ited  the 
vdiide.  It  is  also  ABC’s  intent  that  this  MDT  activity  will  collect  and  transmit  the  following 
information  to  the  MDCS  computer 

1.  ali^iting  activity, 

2.  rider  identification  number, 

3 .  dispatch  system  generated  trip  number, 

4.  vehide  identification  number, 

5.  time  and  date  of  transmission, 

6.  vdnde  odometer  reading,  and 

7.  vdiide  loi^itude  and  latitude. 

9.12  Rider  Call  Out 

It  is  ABC^s  intent  that  drivers  will  use  the  MDT  to  request  a  rider  call  out.  It  is  also  ABC^^  intoit 
that  this  MDT  activity  will  collect  and  transmit  the  following  information  to  the  MDCS  computer. 

1.  call  out  request, 

2.  rider  identification  number, 

3..  dispatch  system  generated  trip  number, 

4.  vehide  identification  number, 

5.  time  and  date  of  transmission, 

6.  vdiicle  odomrter  reading, 

7.  vehicle  longitude  and  latitude,  and 

8.  call  out  request  approved  or  disapproved. 
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9.13  Rider  No  Show 

It  is  ABC’s  intfint  that  drivers  will  use  the  MDT  to  request  permission  to  conduct  a  rider  no  show. 

It  is  also  ABC’s  intent  that  this  MDT  activity  will  collect  and  transmit  the  following  information  to 
the  MDCS  computer; 

1.  no  show  request, 

2.  rider  identification  number, 

3 .  dispatdi  system  generated  trip  number, 

4 .  vehicle  identific^on  number, 

5 .  time  and  date  of  transmission, 

6.  vehicle  odometer  reading, 

7.  vehicle  longitude  and  latitude,  and 

8.  no  show  approved  or  disapproved. 

9.14  Rider  Door  Cancellation 

It  is  4  RC’s  intent  that  drivers  will  use  the  MDT  to  indicate  that  a  rider  has  cancded  the  trip  at  the 
pick  iq)  site.  It  is  also  ABC’s  intent  that  this  MDT  activity  will  collect  and  transmit  the  following 
information  to  the  MDCS  conq)uter: 

1.  door  cancdlation, 

2.  rider  identification  number, 

3 .  dispatch  system  generated  trip  number, 

4.  vdiicle  identification  number, 

5 .  time  and  date  of  transmission, 

6.  vdiide  odomder  reading,  and 

7 .  vehicle  longitude  and  latitude. 

9.14  Rider  Fares 

It  is  ABC’s  intent  that  drivers  will  use  Form  Screais  to  collect  and  transmit  the  following  rider, 
attpndant  and  companion  fare  information:  fare  amount,  fare  type  such  as  cash,  pass,  ticket,  token, 
transfer,  etc. 
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Paratran^  Systems 

Si.c=m8,M«.orsys««.h,ve,ucc=ssMy»«»..U-dU,gcfle..d.pa.^^^^^^ 

industries  across  North  America  and  Intemationally. 


SanteFeRide 
Contact:  Rob  McArthur 
Ph.  (505)  438-1463 


System  Description  -  We  Implemented  24  MDTs  ID  cetd  madets  for  passenger 
telegiated  smart  taxi  meters  to  track  individual  taxi  fare  amounts. 


validation  as  well  as 


Soudt  West  Metro  Transit 
Contact:  Tom  Juhnke  or  Chuck  Snyder 
Ph.  (612)  934-7928 

System  Description  -  This  system  is  operating  over  a 
(typically  14  vehicles  are  operational  at  one  time). 


Johnson  LTR  radio  system  and  has  22  MDTs 


Stanislaus  County 
Contact:  Troy  Holt 
Ph.  (209)  525-6552 


system  Description  - 10  MDTs  witn  GPS  receivers  and  odometer  monitoring  opemting 
conventional  radio  system  on  a  community  repeater. 


over  a 


Anoka  Trar  H 
Contact:  Tim  Kirchoff 
Ph.(612)427.7088 


System  Description  -  Anoka's  16  vehicle  fleet  was  equipped  with  the  Express 


MDT. 


Sunvan  -  City  of  Albuquerque 
Contact:  Dan  Hogan 


Ph.(505)764-6185 

of  plus  or  minus  eight  meters. 


Other  Paratransit  Projects 

Everett  Transit  -  Everett,  WA  - 1 1 
BiState  Transit  -  Saint  Louis,  MO  -  80  vehicles 
Pierce  County  -  Tacoma,  WA  -  88  vehicles 
STS  -  Charlotte,  NC  -  63  vehicles 


other  System  References 


Checker  Cabs 
Contact:  Wayne  Maki 
Ph.  (403)  299-4950 

System  Description  -  Checker  Cabs  operates  a  taxi  fleet  of 550  vehicles  with  our  EXPRESS  MDT  and  an 
in-house  software  system.  This  system  is  operating  over  conventional  (VHP)  radio. 


Boston  Coach  Limousine  (Fidelity  Investments) 

Contact:  Doug  Collette 
Ph.  (617)  563-6375 

System  Description  -  Boston  Coach  operates  a  black  car  style  of  service  in  the  Boston  area.  Their  fleet  is 
over  135  vehicles  in  the  Boston  area  and  they  are  using  an  in-house  dispatch  software  package.  Radio 
backbone  is  the  Johnson  LTR  radio  system. 


Petro  Canada  Inc.  (Oil  and  Gas  Exploration) 

Contact:  Walter  Geist 
Ph.  (604)  785-4431 

System  Description  -  Petro  Canada’s  field  operators  are  using  over  100  of  Mentor’s  mobile  data  terminals 
to  access  information  and  receive  alarms  firom  gas  compressor  sites  and  MAN  DOWN  alarms. 


CO-OP  Taxi  Line 

Contact:  Rita  Curtiss  /  Connie  Loeder 
Ph.  (403)  425-0954 

System  Description  -  CO-OP  replaced  meir  Gandalf  MDTs  with  Mentor’s  EXPRESS  MDT  in  their  fleet  of 
480  vehicles. 


AAA  -  Florida  -  Heathrow,  FL 
Contact:  O.S.  Brannon 
Ph.  (407)444-4360 

System  Description  -  AAA  Florida  has  installed  Express  MDTs  in  200  of  their  contractor’s  tow  trucks.  The 
RAM  network  was  chosen  as  the  wireless  link  fi’om  the  dispatch  office  to  the  trucks  in  the  field  because  of 
it  provided  the  best  coverage  and  capacity  available. 


Alberta  Motor  Association  (AMA)  -  Edmonton,  AB 

Contact:  Alec  Strap 

Ph.(403)430-5554 

System  Description  -  The  Express  MDT  is  installed  in  the  Alberta  Motor  Association’s  fleet  of  140  trucks 
in  the  cities  of  Calgary  and  Edmonton.  The  Express  Gateway  was  integrated  into  the  AMA’s  in-house 
software  package  and  also  a  combined  VHF  and  UHF  radio  system. 
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Mentor  MDT  Functionality 
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Express  Mobile  Data  System 

Paratransit  System  Technical  Specifications 


Overview 


Hardware 

The  MDT  hardware  should  consist  of  a  single  enclosed  unit  so  that  it  is  easily  installed  in 
the  vehicle.  The  unit  should  house  a  display,  keypad,  radio  modem,  and  GPS  receiver  (if 
required). 


The  MDT  should  be  compact  It  should  be  no  larger  than  10”W  by  3”H  so  that  it  is  easily 
mounted  and  unobtrusive. 


The  MDT  should  feature  a  rugged  aluminum  enclosure. 

The  MDT  should  feature  a  membrane  keypad  with  no  moving  parts  to  increase  longevity. 
The  MDT  should  operate  from  -40°F  to  1 50°F 

The  MDT  display  should  have  Hilly  adjustable  contrast  so  that  the  changes  in  temperature 
will  not  affect  the  driver's  ability  to  read  the  display. 


The  MDT  should  have  a  4  line  by  40  transflective  display  with  eight  levels  of  backlighting 
so  that  the  driver  will  be  able  to  read  the  display  under  all  lighting  conditions. 

The  MDT  should  feature  LED  indicators  that  indicate  the  transmission  of  data,  and  receipt 
of  messages. 

Functional  Overview 

The  system  has  to  be  able  to  transmit  from  the  central  dispatch  to  specific  vehicles  the 
following  information ; 

1)  Passenger  name 

2)  Passenger  pick-up  address  including:  number,  street,  dty,  apartment/suite 

3)  Passenger  drop-off  address  including:  number,  street,  dty,  apartment/suite/doctor 

4)  Passenger  spedal  equipment  information:  wheelchair,  walker,  oxygen,  etc. 


5)  Passenger’s  scheduled  pick-up  time 

6)  Passenger’s  destination  appointment  time 

7)  T otal  number  of  passengers 

8)  Canceled  trip 

9)  Thomas  brothers  map  page  and  location  reference 

1 0)  Special  text  instnjctions  or  messages 

MDT  should  sort  jobs  based  on  their  priority  and  the  driver’s  schedule  so  that  the  job  on 
the  top  of  the  screen  will  always  be  the  next  for  the  driver  to  perform. 


System  should  be  able  to  insert  additional  trips  into  a  group  of  trips  that  has  already  been 
sent  to  the  MDT  in  a  specific  pick-up  and  drop-off  order. 

The  MDT  should  automatically  acknowledge  the  receipt  of  infomiation  from  the  dispatch 
office. 


Each  MDT  must  have  a  unique  ID  number  and  a  method  for  grouping  them  that  can  be 
used  to  separate  vehicle  types  ( i.e.  supervisor,  wheelchair,  non-smoking,  etc.) 


All  messages  (except  broadcasts)  should  receive  automatic  acknowledgments  from  the 
receiving  unit  to  verify  a  completed  transmission.  Should  a  transmission  fail  the  message 
would  be  automatically  retransmitted  a  programmable  number  of  times.  In  the  case  of 
communications  failure  the  driver  must  be  notified  that  an  error  has  occurred.  In  addition 
the  MDT  should  have  an  LED  light  indicating  channel  quality. 


MDT  should  store  a  minimum  of  eight  structured  forms  or  message  formats 

MDT  shouid  store  received  messages  and  give  the  driver  both  visual  (message  LED 
flashes)  and  audible  (programmable  beeping  sequences)  indication  of  a  new  message 
arrival.  Priorities  assigned  to  incoming  messages  allow  the  driver  to  see  important 
messages  immediately  while  less  important  messages  can  be  stored  for  the  driver  to 
retrieve  later. 


The  MDT  should  support  free  form  text  messaging  for  general  information  and  personal 
messaging. 


The  ability  of  the  dispatcher  to  send  “Yes/No”  or  “Accept/Rejecf  messages  means  that  the 
driver  can  be  prompted  to  take  a  course  of  action. 


The  dispatcher  should  be  able  to  be  reassign  jobs  from  one  MDT  to  another,  change  job 
information,  and  delete  jobs  from  the  MDT  in  case  of  cancellation  or  reassignment. 


MDT  must  be  able  to  transmit  data  from  a  specific  vehicle  to  the  central  dispatch  and 
update  corresponding  information  in  the  dispatch  system  such  as: 

1 )  Driver  acknowledged  receipt  of  pick-up 

2)  Time  driver  arrived  at  passenger  pick-up 

3)  Time  passenger  picked-up 

4)  Time  passenger  arrived  at  destination 

5)  Time  passenger  dropped  off 

6)  T rip  odometer  reading 

7)  Rider  fare  information 

8)  T ota!  number  of  passengers 

9)  Confirmation  of  canceled  trip  Initiated  by  dispatcher 

10)  Passenger  no-show  (to  be  verified  by  dispatcher) 

11)  Additional  programmable  messages 

MDT  must  be  capable  of  the  following  criteria: 

1)  Ability  to  sort  rides  on  a  numeric  field 

2)  Host  clearing  of  rides 

3)  Receive  messages  from  the  host 

4)  T ransmit  canned  messages  to  the  host 

5)  Send  data  in  a  preset  format  to  the  host 

MDT  Display 

MDT  will  display  trip  information  on  both  manifest  view  and  expanded  view  display 
screens. 

Manifest  view  consists  of  a  single  line  entry  for  ail  the  available  trips  with  the  current  trip 
being  highlighted.  The  driver  should  be  able  to  view  available  trips  not  currently  on  the 
display  by  scrolling  up  or  down 

Expanded  view  allows  the  driver  to  view  detailed  information  about  any  one  trip.  Pressing 
the  function  key  that  corresponds  to  a  particular  trip  should  enable  the  driver  to  see  the 
expanded  view  of  that  trip. 

MDT  should  be  able  to  support  peripheral  devices  such  as: 

1)  AVL7GPS  receivers 

2)  Card  readers/bar  code  readers 

3)  Printers 

4)  Odometer  loggers 


Function  Keys 

The  MDT  should  provide  programmable  function  keys  for; 

1)  Login 

2)  Arrivai 

3)  Pick-up  Made 

4)  Drop-off  Made 

5)  No-show 

6)  Renew 

7)  Page-up 

8)  Page-down 

9)  Mail 

10)  Snd/Msg 

11)  Message  Confirmed 

12)  Request  to  Talk 

13)  Available 

14)  Emergency 

15)  Breakdown 

16)  Clear  to  Garage 

Function  keys  will  automatically  change  depending  on  the  information  displayed  on  the 
screen  thereby  reducing  driver  keystrokes. 

The  MDT  should  display  these  functions  in  a  vertical  list  on  the  MDT. 

The  MDT  should  have  macros  associated  with  its’  function  keys  so  that  a  number  of 
functions  can  be  performed  with  a  minimum  number  of  driver  keystrokes. 


Additional  Features: 


VIEW  NEW  function  key  -  Should  the  driver  receive  multiple  new  messages  and  is  not 
sure  of  what  information  is  new.  the  VIEW  NEW  function  key  allows  the  driver  to  scroll 
through  the  new  information  in  the  order  that  it  was  received.  New  information  could  be 
any  combination  of  general  manifest  information,  personal  messages  etc. 

Store  and  Forward_-  Should  the  data  transmission  fail,  the  MDT  will  wait  a  specified 
(programmable)  time  period  and  then  automatically  retry  the  message  transmission.  The 
original  time  stamp  and  odometer  will  be  maintained. 


Quick  Keys  -  Function  keys  can  be  hard  coated  on  to  the  MDT  keypad  overlay  to  provide 
easy  access  to  common  functions.  Custom  graphics  can  also  be  added  to  the  MDT 
overlay. 


Fare  Structure  Programmability  -  Mentor  can  customize  the  MDT  data  entry  structure 
on  fare  codes  to  meet  the  specific  requirements  of  the  Paratransit  operation.  Our  function 
keys  can  have  macros  programmed  with  them  so  when  the  driver  pusiies  a  PERFORM  or 
FARE  key,  the  driver  can  be  prompted  to  enter  in  information  particular  to  the  individual 
requirements.  The  data  entry  can  be  either  one  level  (e.g.  driver  only  prompted  to  enter  in 
one  piece  of- information  or  multiple  levels  where  the  driver  can  enter  in  multiple  pieces  of 
information 


ID  Card  Matching  -  When  a  passenger  swipes  their  ID  card,  the  MDT  will  match  the 
incoming  ID  information  to  the  appropriate  trip  on  the  MDT  screen.  Once  the  match  is  met, 
the  MDT  will  send  in  a  PERFORM  function  automatically. 


Future  Communication  System  -  Should  at  anytime  the  radio  frequencies  of  the 
contractors  be  refarmed  by  the  FCC  or  for  any  reason  the  current  communication  systems 
be  unavailable  for  use  in  the  future,  the  MDT  is  fully  compatible  with  alternative  wireless 
data  networks  such  as  RAM  Mobile  Data,  Ardis,  CDPD,  and  GE  EDACs. 
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B 


Products 


Express  Plus  Mobile  Data  Tenninal  (MDT) 


Price  includes  a  built-in  radio  modem,  a  basic  mounting  bracket,  and  a  standard  keypad 
overiay.  An  internal  eight  channel  GPS  receiver  is  optional. 


In-Vehicle  Configuration 


Two  Way  Radio 

(or  Data  Network  Modem! 


Express  Plus  MDT 


Optional  Peripherals 


Card  Reader  Keytxjard  Monitoring  Printer  GPS  Receiver 


/Express  Pius  Master  Communications  Controller  (MCC^ 

The  MCC  provides  the  interface  between  the  host  computer  and  the  base  station  radio 
equipment  The  MCC  must  be  located  at  the  base  station  radio.  If  this  base  station  is  remote 
from  the  host  software  system,  a  dedicated  land  line  connection  is  required.  We  typically  use 
Motorola  UDS  V.3225  modems  for  this  connection. 

XGate  Software  License 

XGate  provides  the  link  between  the  host  software  system  and  the  Express  Plus  mobile  data 
equipment  This  software  module  resides  on  a  PC  that  would  be  part  of  the  PC  network 
operating  the  dispatch/data  collection  application. 

XGate  will  support  multiple  channels  (up  to  16)  which  can  consist  of  MCCs  or  links  to  3rd 
party  data  networks  such  as  RAM/Ardis/CDPD/Satellite.  This  Gateway  also  provides  a  data 
logging  feature  for  system  diagnostics. 


Dispatch  Office 


Computer  Aided  XGate 

Dispatching  Software 
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E.  Communication  System  Summary 


The  communication  system  was  not  idenfified  for  the  purposes  of  this  proposal  so  all  radio 
related  engineering  fees  have  been  based  on  a  conventional  radio  system  with  mobile  radios 
that  we  have  previously  used  for  such  a  project 


F.  Project  Flow 


This  project  will  require  a  phased  implementation  as  follows: 

Raiiio  System  Evaluation  Phase 

Mentor  Engineering  will  provide  an  on-site  engineer  for  a  period  of  one  week  to  evaluate  the 
coverage  and  capacity  cf  the  proposed  communications  system.  The  goal  of  this  phase  is  to 
determine  the  suitability  of  the  proposed  radio  system  for  data  communications.  The  following 
items  will  be  required  of  Chapel-Hill  to  fecilitate  this  testing: 

■  A  data  group  set-up  on  the  radio  system  for  the  evaluation  period. 
m  A  vehicle,  driver,  and  test  route  for  coverage  testing. 

m  Three  spate  mobile  radios:  initially  sent  to  Mentor  for  interface  testing  and  then  provided  to 
the  communications  provider  for  bench  testing. 

The  system  evaluation  phase  will  consist  of  the  following  sequence  of  events: 

■  Mentor  will  provide  the  communications  service  provider  with  the  appropriate  installation 
guide  for  the  mobile  radios  so  that  both  preliminary  setup  and  testing  is  completed  before 
an  engineer  arrives  on  site.  Radio  interfaces  to  at  least  three  mobiles  v/ill  be  completed  by 
the  communications  provider  prior  to  Mentor  arriving  on  site. 

■  The  first  stage  of  the  system  evaluation  is  a  coverage  test  Mentor’s  project  engineer  will 
test  the  coverage  of  the  radio  system  under  normal  operating  conditions  and  plot  the 
results  geographically.  If  upon  a  review  of  the  test  results  rt  is  concluded  that  the  radio 
system  coverage  is  inadequate  methods  to  improve  the  current  system’s  coverage 
characteristics  and/or  other  communications  options  will  have  to  be  investigated. 

■  The  second  stage  of  testing  is  a  series  of  loading  tests,  conducted  to  gather  channel 
capacity  data.  The  engineer  will  configure  the  radio  system  as  it  will  be  configured  for  the 
system  installation  and  then  log  the  results  of  a  series  of  tests  using  the  'auto-exercise' 
utility  of  Mentor's  XGate  software.  Both  of  the  mobile  radios  interfaced  by  the 
communications  provider  prior  to  the  on-site  visit  would  be  requited  for  this  stage  of  the 
testing. 

Once  the  performance  of  the  radio  system  has  been  signed  off  as  being  satisfactory  by 
Mentor,  Trapeze,  and  Chapel-Hill .  the  project  will  proceed  with  the  pilot  phase. 

Pilot  Phase 

The  goal  of  the  pilot  phase  of  the  project  is  to  prove  oti  the  end-to-end  operation  of  the  system 
wth  a  small  group  of  vehicles.  Mentor  will  provide  an  on-site  engineer  for  a  period  of  one  week 
during  the  pilot  phase.  Chapel-Hill  will  again  be  required  to  supply  a  data  group  on  the  radio 
system  during  the  pilot  phase  to  facilitate  testing. 

The  pilot  phase  will  consist  of  the  following  sequence  of  events: 


5-3 
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■  Mentor  will  ship  the  cxjmmunications  provider  five  (5)  complete  sets  of  in-vehicle  hardware 

including  Express  Plus  MDTs  Dne-proaiammed  with  the  appropriate  firmware,  cabling. 
apri  stands  TheTcornmuniSti^s  provider  will  install  and  test  the  equipment  in  five  of 
ChapeH-UH's  vehicles  betore  Mentor  staff  amv^^  ~  ~ 

■  Mentor  will  pre-configure  the  XGate  PC  and  ship  it  to  Chapel-Hill.  Chaoel-Hill  will  be 
tyscnn'ribM^''  pnniiHing  >ip-ira  pn»<pr,  anri  a  nptvicrk  Connection  for  the  XGate  PC.  The 
XGate  PC  needs  to  be  installed  within  fifty  teet  of  the  dispatch  radio. 

■  Mentor's  on-site  staff  will:  establish  communications  on  the  radio  system;  bring  the  pilot 
vehicles.on-line;  perform  XGate  logging  of  data  communications;  prove  out  the  operation 
of  the  mobile  data  system  with  the  host  MDT  application  running:  evaluate  the  system 
performance;  and  deal  with  minor  issues  as  they  arise. 

Once  the  end-to-end  operation  of  the  system  has  been  proven  to  the  satisfaction  of  Mentor, 
Trapesze,  and  Chapel-Hill  and  signed  off  on  the  next  phase  will  proceed. 

System  Roll-out  Phase 

The  goal  of  the  system  roll-out  phase  is  to  complete  the  implementation  of  the  mobile  data 
system.  This  phase  consists  of  the  following  sequence  of  events: 

■  Mentor  will  ship  the  remaining  in-vehicle  hardware  to  the  communications  provider,  who 
will  then  proceed  with  the  remaining  hardware  installations. 

B  Mentor  personnel  will  provide  roll-out  support  while  remaining  units  are  brought  on-line  to 
monitor  communications  and  deal  with  any  issues  that  may  arise. 

Upon  successful  completion  of  system  roll-out  to  all  parties’  satisfaction,  and  the  elimination  of 
any  outetanding  issues,  a  system  sign-off  will  be  circulated. 

System  Acceptance  Phase 

For  a  period  of  sixty  (60)  days  following  the  system  sign-off  Mentor  will  provide  engineering 
support  for  the  system  free  of  charge.  This  phone  support  is  limited  to  the  hours  of  8:00  AM  to 
5:00  PM  MST  from  Monday  to  Friday  (excluding  statutory  holidays).  This  support  does 
exclude  any  system  modifications  as  defined  in  the  “Ongoing  Supporf  section  of  this 
document 
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G.  Mobile  Data  System  Costs 


All  pricing  quoted  is  in  US  dollars,  does  not  include  any  applicable  taxes,  and  is  FOB  Calgary. 

Note:  all  radio  shop  support  figures  assume  the  city  radio  shop  could  be  sub-contracted  for 
$320/day.  Higher  city  rates  and/or  the  use  of  a  private  radio  shop  would  require  adjustments  to 
the  Radio  Shop  Support  fees  listed  herein. 

Radio  System  Evaluation  Phase 


ITEM 

Unit  Price 

Quantity 

Total  I 

1 

Engineering  -  On-site‘ 

$5,000 

1 

2 

Radio  Shop  Support  (Set-up,  Training) 

■EBB 

5 

1,600 

Total 

$6,600 

Includes  travel  and  living  expenses. 


Pilot/  Roli-out  Phase 


n 

ITEM 

Unit  Price 

Quantity 

Total 

n 

Express  Plus  MDT 

$1,200 

8 

$9,600 

m 

MDT  Cabling 

$69 

8 

552 

m 

Express  Plus  MCC 

$1,895 

2 

3,790 

■n 

MCC  Install  Kit 

$150 

2 

300 

XGate  Software  Ucense 

$1,400 

1 

1.400 

7 

XGate  PC  ( pre<x)nfigured) 

$3,950 

1 

3,950 

8 

Engineering  -  On-site  (per  week)"^ 

$5,000 

1  ! 

9 

Engineering  -  Project  Management 

$2,500 

1  ' 

2,500 

■Q 

Radio  Shop  Support  (Installation) 

$320/day 

8 

2,560 

□ 

Total 

$27,390 

‘Includes  travel  and  living  expenses. 


Finnware  Customization 

Merrtor  Engineering  will  supply  any  customization  to  the  MDT  firmware  at  a  rate  of  $90/hr. 

GPS  Option 


ITEM 

Unit  Price 

Quantity 

Total 

1 

Internal  8  Channel  GPS  Receiver‘ 

$495 

8 

$3960 

2 

Radio  Shop  Support-Installation 

$320/day 

1 

320 

Total 

$4,280 

‘Includes  direct  mount  antenna  and  cabling.  Internal  receivers  must  be  adered  at  the  same 
time  as  the  MDTs. 


From:  Brent  Freer  Mentor  Engineering  Fa>c  403-777-3769  Voice:  403-777-3764  To:  ICelly  Maroni  at  Chapel-HIH  Transit 


Page  1 1  of  14  Wednesday.  March  26. 1997  8:42:01  AM 


Odometer  Monitoring  Option* 


ITEM 

Unit  Price 

Quantity 

Total 

1 

Odometer  Transducer  &  Cabling 

$89 

8 

$712 

Total 

$712 

’Installation  has  not  been  included  in  this  quote.  Chapet-Hill’s  local  vehicle  maintenance 
provider  would  be  the  most  qualified  to  complete  Itiis  task.  Mentor  will  provide  support  with 
regards  to  identifying  the  proper  installation  procedure. 


Extended  Warranty  Fees 

The  Express  MDT  comes  with  a  two  (2)  year  warranty  and  the  MCC  a  three  (3)  year  warranty. 
The  following  edended  warranty  pricing  covers  MDT  repair/replacement  and  return  shipping. 
The  ©(tended  warranty  fee  would  be  added  to  the  base  price  cf  the  MDT  at  the  time  of 
purchase. 


Extended  Warranty 

Price 

Rrst  2  Years  of  Warranty 

included 

3  Years  Total  Warranty 

$72 

4  Yrars  Total  Warranty 

$145 

5  Years  Total  Warranty 

$220 

On-going  Support 

This  section  outlines  the  various  levels  of  ongoing  support  and  services  available  from  Mentor 
Engineering  over  the  lifetime  of  the  mobile  data  system. 

Support  Plans 

Following  the  sixty  day  acceptance  phase  Mentor  will  provide  XGate  Maintenance  and  phone 
support  to  the  customer  under  a  yearly  plan.  The  support  plan  includes  XGate  Maintenance,  a 
yearly  fee  that  provides  the  customer  with  an  unlimited  warranty  on  the  XGate  software 
package,  as  well  as  50  hours  of  phone  support 


Plan 

Hours  of  Phone  Support 

XGate  Maintenance 

Each  call  will  be  subject  to  a  20  minute  minimum  charge.  Mentor  will  track  the  amount  of 
support  time  already  used  that  calendar  year  and  update  Chapel-Hill  upon  request 
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Moba*  Data  System  Analysis 

Mentor  Engineering  will  also  prcMde  scheduled  system  analysis  services  to  customers.  These 
services  include: 

■  analyzing  the  customer's  communication  logs 

■  presenting  the  customer  with  a  graphical  representation  of  the  results 

■  providing  a  written  summary  of  the  results  and  any  recommendations  to  increase  system 
dliciency 

Mentor  will  provide  these  system  analysis  services  under  any  of  the  following  plans; 


Plan 

Schedule 

Cost 

Level  One 

S550 

Level  Two 

Biannually 

$950/year 

Level  Three 

Quarterly 

Note:  These  charges  are  based  on  the  system  operating  over  a  single  communications 
network.  Additional  communications  networks  would  require  a  separate  analysis  to  be  done. 

System  ModHicafions 

Mentor  will  supply  system  modifications  to  the  customer  on  a  per  project  basis.  Modffications 
to  the  system  should  occur  after  the  system  has  been  running  for  a  reasonable  period  of  time 
and  should  tal«  into  account  input  from  the  vehicle  operators.  Mentor  will  quote  the  following 
services  on  a  per  project  basis. 

■  changes  to  the  communications  network 

■  changes  to  the  host  software  (dispatching  application) 

■  CAPP  file  modifications 


H.  Options 


Optional  Equipment 

Mentor  can  supply  any  of  the  following  peripheral  devices  and  equipment  installation  products; 


Options* 

PriceAJnrt 

Trimble  SVeeSix  GPS  Receiver  (external) 

$600 

Card  Swipes  -  Magnetic 

$135 

Mobile  Printers 

$595 

Pedestal  Mount  -  telescopic  +  swivel  adjust 

$95 

$950  +  $12/MDf 

‘Introdixtion  of  some  optional  peripherals  may  require  MDT  firmware  customization. 


